Re: O(1) scheduler & interactivity improvements

[Bill Davidsen <davidsen@tmr.com>]

On Sat, 28 Jun 2003, Mike Galbraith wrote:

> At 11:51 PM 6/27/2003 -0400, Bill Davidsen wrote:
> >Why do it at wakeup. Is it easier to just decide at the time of the
> >processes blocking to decisde there if it is blocking on an interactive
> >transaction? Is it that easy or is it really necessary to make the process
> >perfect?
> 
> I'm no clean freak, but fiddling with scheduling information all over the 
> place seems like a very bad idea. (before anyone says it, yes, we fiddle 
> with state all over the place;)  I can imagine doing something dirty in 
> driver code for specific cases (kdb/mouse are always interactivity 
> indicators), but not in generic code.
> 
> Besides, the logical bindings for foo | bar | ... | baz do not exist in the 
> kernel.  The kernel knows and cares only that single entities are using 
> open/read/write/close primitives.  This is why I said I could _imagine_ a 
> process struct... as the container for this missing (it lives in userland) 
> information.
> 
> Another besides:  it makes zero difference it you add overhead to wakeup 
> time or go to sleep time.  If it's something you do a lot of, adding 
> overhead to it is going to hurt a lot.

True, but at block time you have more information. If a process blocks on
pipe read, presumably it's in the pipe read code that the process is
blocked, and that code is not common to disk read, keyboard read, socket
read, etc. Atleast not all of it is...

If you try to do something at unblock, you have to determine why the
process blocked. But if you do it at block time you have that information.
Therefore you should have a lot less overhead to add, which is why I think
it's a win over finding "what happened?" at unblock.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.