lkml.org 
[lkml]   [2003]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: O(1) scheduler & interactivity improvements
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;)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:36    [from the cache]
©2003-2011 Jasper Spaans