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