Subject: Re: the reaper
To: Jason R Thorpe <thorpej@zembu.com>
From: Chuck Cranor <chuck@research.att.com>
List: tech-kern
Date: 01/10/2001 21:38:56
On Wed, Jan 10, 2001 at 05:58:42PM -0800, Jason R Thorpe wrote:
> Yes, that could be done. However, that means that the unsuspecting
> process can be charged for time accumulated by reaping the process,
> not necessarily something you want (or, it could block, and if it's
> a very high priority process, you don't want that, either).
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?)
in the mean time, the rub is that the reaper inserts an extra two
un-necessary hardware context switches at process exit time.
> Another nice thing about the reaper is that it can be made into a
> very low priority thread, effectively creating a pool of contexts
> that can be re-used at thread creation time ... this is something
> that Solaris does, although our reaper does not (yet).
ok, but does having that pool of contexts for reuse require
having a reaper process, or is having a reaper process an
orthogonal issue?
chuck