| |||||||||||||
|
| |||||||||||||
Why not a strait forward approach.Why not a strait forward approach.Posted Mar 15, 2007 19:02 UTC (Thu) by aashenfe (subscriber, #12212)Parent article: RSDL hits a snag
Wouldn't it be better to determine interactivity of a process based on it's interaction?
So priority would be based on the hardware driver a process interacts with.
For instance, everytime a process sends (or receives) data to the sound system, it would be given a short term boost. It would continue to have the boost as long as it continues to send or receive data. Also sound is the system were you really notice the problems with so processes doing sound would get the most boost.
Next would be keyboard and mouse events. If I type on open office for instance, it should get a moment of increased priority so that it can draw the new character I type to the screen faster. Plus if I'm trying to get control back on a runaway server, it would be nice if my processes had priority.
Interacting with the screen might provide a small boost as well, but might be to easy to abuse. Movies and games usually come with sound and thus would get a boost anyway.
Most other hardware subsystems would probably not (and shouldn't) have an effect on the priority of a process.
It sounds like a nice idea, and maybe it is already done this way, or maybe there is a lot more to it that I haven't considered (Like isn't X always the one getting keyboard and mouse events?).
(Log in to post comments)
Why not a strait forward approach. Posted Mar 16, 2007 17:31 UTC (Fri) by vmole (guest, #111) [Link] Because such an approach is not, in fact, straight-forward. The current scheduler does attempt to identify "interactiveness" and boost such processes. The problem is that the heuristics involved are complicated and not at all obvious, leading to a lot of dissastifaction among the kernel developers; one gets the impression that Linus tolerated the current scheduler only because nothing better was available. There's a *lot* of enthusiasm on the lkml for RSDL, I doubt a few corner case regressions will keep it out, because *all* of the schedulers have bad corner cases, and making them more complicated doesn't seem to prevent that, it just moves them around.
Why not a strait forward approach. Posted Mar 18, 2007 18:59 UTC (Sun) by nlucas (subscriber, #33793) [Link] (Like isn't X always the one getting keyboard and mouse events?).Yes and the same with sound daemons, which are separate processes from it's users. On Windows it's easier for the scheduler because the graphics sub-system (or part of it) is part of the kernel, which means an application with a foreground window does have a priority boost.
Why not a strait forward approach. Posted Mar 18, 2007 19:41 UTC (Sun) by aashenfe (subscriber, #12212) [Link] So then what would really need to happen is X or a sound daemon would somehow need to give some of it's priority to processes they interact with. These programs would either have to consciously be written to do this, or some kind of heuristic would be used.
It is a little easier for Windows, but I'm not sure if giving a priority boost to the foreground window application is always the best.
Why not a strait forward approach. Posted Mar 18, 2007 20:41 UTC (Sun) by nlucas (subscriber, #33793) [Link] It is a little easier for Windows, but I'm not sure if giving a priority boost to the foreground window application is always the best.
I was over-simplifying, off course. I'm no scheduling master, I just happen to have read the "Windows Internals" book by Mark Russinovich and David Solomon. There are differences between Windows versions, so if you really want to learn more (and not only about this) I would advise you to get that book.
Why not a strait forward approach. Posted Mar 24, 2007 20:19 UTC (Sat) by pimlott (guest, #1535) [Link] There is a classic story of a clever user who figured out that his compile would run faster if he hit the space bar every once in a while. :-)
|
|
||||||||||||