Re: O(1) scheduler & interactivity improvements

[Mike Galbraith <efault@gmx.de>]

At 10:50 AM 6/26/2003 -0400, Bill Davidsen wrote:
>On Thu, 26 Jun 2003, Helge Hafting wrote:
>
> > This can be fine-tuned a bit: We may want the pipe-waiter
> > to get a _little_ bonus at times, but that has to be
> > subtracted from whatever bonus the process at the
> > other end of the pipe has.  I.e. no new bonus
> > created, just shift some the existing bonus around.
> > The "other end" may, after all, have gained legitimate
> > bonus from waiting on the disk/network/paging/os, and passing
> > some of that on to "clients" might make sense.
> >
> > So irman and similar pipe chains wouldn't be able to build
> > artifical priority, but if it get some priority
> > in an "acceptable" way then it is passed
> > along until it expires.
> >
> > I.e. "bzcat file.bz2 | grep something | sort | less" could
> > pass priority down the chain when bzcat suffers
> > a long nfs wait...
>
>This is the case which worries me, passing back the priority of the
>process which is waiting for user input. It's desirable, but hard to do
>and subject to unintended boosts.

The thought of building/passing "connection" information around in the 
scheduler gives me a bad case of the willies.  I can imagine a process 
struct containing a list of components and their cpu usage information as a 
means to defeat fairness/starvation issues, but I can't imagine how to do 
that and retain high speed low drag O(1) scheduling.

Until someone demonstrates that the DoS/abuse scenarios I might be 
imagining are real, in C, I think I'll do the smart thing: try to stop 
worrying about it and stick to very very simple stuff.

         -Mike

(heck, i don't know why i'm even _thinking_ about it.  plain white cone 
doesn't cut it, and there's a "you have to be this tall" line at the 
entrance to the wizards section of the hat store;)