On Mon, 2003-08-04 at 22:55, Andrew Morton wrote:

> There is a very good argument for giving !SCHED_OTHER tasks
> "special treatment" in the VM.

Yes, there is.

Attached patch is against 2.6.0-test2-mm4. It does two main things:

- Let real-time tasks dip further into the reserves than
usual in __alloc_pages(). There are a lot of ways to
special case this. This patch just cuts z->pages_low in
half, before doing the incremental min thing, for
real-time tasks. I do not do anything in the low memory
slow path. We can be a _lot_ more aggressive if we want.
Right now, we just give real-time tasks a little help.

- Never ever call balance_dirty_pages() on a real-time
task. Where and how exactly we handle this is up for
debate. We could, for example, special case real-time
tasks inside balance_dirty_pages(). This would allow
us to perform some of the work (say, waking up pdflush)
but not other work (say, the active throttling). As it
stands now, we do the per-processor accounting in
balance_dirty_pages_ratelimited() but we never call
balance_dirty_pages(). Lots of approaches work. What
we want to do is never engage the real-time task in
forced writeback.

It compiles, it boots, and it does not crash. I have not tested whether
it prevents any starvation in real-time applications that are being
observed -- mostly because I am not sure if my approach is what you
want. There are multiple ways to handle the real-time task path. I
picked one. I do not know.

Robert Love