Messages in this thread | | | Date | Fri, 27 Jun 2003 08:36:48 +0200 | From | Mike Galbraith <> | Subject | Re: 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/
| |