On Wed, Jan 10, 2001 at 09:38:56PM -0500, Chuck Cranor wrote:

 > sure, but that points to an underlying problem with the 
 > interrupt-driven accounting mechanism that the kernel currently
 > uses.  there are a lot of unsuspecting processes out there.  (e.g.
 > how do you account for interrupt-level network processing?)

Yes, there are problems with interrupt-driven processing accounting.

However, even if you fix that, the possibility of a high-priority
thread having to possibly block is still there if you don't use
the reaper.

 > in the mean time, the rub is that the reaper inserts an extra two 
 > un-necessary hardware context switches at process exit time.

Actually, that's an implementation matter ... We can make the reaper
thread very low priority such that it only runs when the idle loop
would be run (this would require a slight change to the run queues,
I think, so that other normal low priority processes wouldn't have
to compete for round-robin slots with the idle-priority threads).

In the event that the reap queue is stacking up and there isn't any
idle time to throw at it, you can dynamically adjust the priority
of the reaper to run, do it's thing, then get out of the way again.

 > ok, but does having that pool of contexts for reuse require 
 > having a reaper process, or is having a reaper process an 
 > orthogonal issue?

The pool_cache mechanism isn't really suited for u-areas ... and
u-areas are generally big enough that you want to have them freed
less lazily than pool pages are.  So, yes, seems like you want to
have some sort of low-priority thread to do this work for you.  I
suppose you *could* make pagedaemon do it, but waking up the pagedaemon
causes all sorts of other work to happen, so it seems to me that
making the pagedaemon do it isn't really what we want.

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>