Messages in this thread | | | Date | Sat, 28 Jun 2003 07:44:26 +0200 | From | Mike Galbraith <> | Subject | Re: O(1) scheduler & interactivity improvements |
| |
At 11:51 PM 6/27/2003 -0400, Bill Davidsen wrote: >On Fri, 27 Jun 2003, Mike Galbraith wrote: > > > > (simple? decode stack, find out where he was sleeping, and then have to > > decide what to do based upon that after _every sleep_? sprinkle > scheduling > > decisions around every place that does wakeups?... i can just imagine Al's > > reaction to someone suggesting that for the VFS... someone better run fast > > and hide well:) > >I'm quoting the above to show I've read you objection, but I think you >have it backward. > > > > >A pipe wakeup can be handled by taking a look at the other end. > > >If the other process has interactivity bonus, grab half of > > >it. (And halve the bonus belonging to that process.) > > >No bonus is created in this case, so no risk of DOS. > > >It is merely redistributed. > > > > > >And it is simple - there is one thing that woke the > > >process up - so only one thing to check. > > > > How? > > > > >Hard corner cases can be avoided. Perhaps bunch of pipes, > > >files, devices, sockets and page-ins becomes ready > > >simultaneosly. A detailed priority calculation is clearly > > >pointless, so just use one of the things - or none. > > > > > >>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. > > > > > >I thought the Irman thing was what killed the previous attempt > > >at redistributing priorities? > > What I think kills the priority redistribution idea is _massive_ > > complexity. I don't see anything simple. You would have to build the > > logical connections between tasks, which currently doesn't exist. Wakeups > > and task switches are extremely light weight operations, and no decision > > you make at wakeup time has a ghost of a chance of not hurting like > > hell. Just using the monotonic_clock() in the wakeup/schedule paths is > > fairly painful. There is just no way you can run around looking for and > > processing "who shot JR" information in those paths (no way _I_ can > imagine > > anyway) without absolutely destroying performance. > >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.
-Mike
- 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/
| |