Messages in this thread | | | Date | Thu, 19 Jun 2003 18:57:53 +1000 | From | Nick Piggin <> | Subject | Re: [PATCH] 2.5.72 O(1) interactivity bugfix |
| |
Mike Galbraith wrote:
> At 05:33 PM 6/19/2003 +1000, Nick Piggin wrote: > >> Mike Galbraith wrote: >> >>> >>> However, that will also send X and friends go off to the expired >>> array _very_ quickly. This will certainly destroy interactive feel >>> under load because your desktop can/will go away for seconds at a >>> time. Try to drag a window while a make -j10 is running, and it'll >>> get choppy as heck. AFAIKT, anything that you do to increase >>> concurrency in a global manner is _going_ to have the side effect of >>> damaging interactive feel to some extent. The one and only source >>> of desktop responsiveness is the large repository of cpu ticks a >>> task is allowed to save up for a rainy day. >>> >>> What I would love to figure out is a way to reintroduce back-boost >>> without it having global impact. I think hogging the cpu is >>> absolutely _wonderful_ when the hogs are the tasks I'm interacting >>> with. Unfortunately, there seems to be no way to determine whether >>> a human is intimately involved or not other than to specifically >>> tell the scheduler this via renice. >> >> >> >> Could certian drivers or subsystems say they are interactive and >> provide some input to the scheduler that way? Reads from input >> devices for example could increase a processes "interactivity" a >> lot, while writes to console or ... no, everything gets multiplexed >> through X, doesn't it... > > > The mouse and keyboard are wonderful candidates for this... there's > always a human connected. It's too bad there's no way to tell if a > human is staring at the display. If I'm mesmerized by xmms gl > eye-candy, it's a highly interactive cpu hog.
Thats right, but console / DRI / whatever could probably provide a small interactivity boost.
> >> The backboost was quite a good idea. I didn't follow it closely >> but what if you impemented the above idea, which increased >> an "interactiveness" number, then X clients could simply have >> their interactiveness value boosted by X? > > > Sounds good. What I'm trying within the current framework is to let > tasks which are extremely light weight (and not kernel threads) do > backboost. Dunno if anything good will come out of it.
OK, the backboost is what? A dynamic priority boost? This is so X for example can be made interactive through its clients even if its hogging a lot of CPU, right?
I think it might be a good idea to introduce an "interactiveness" measurement which could be boosted by interactive devices, and a forwardboost would be able to increase an X client's interactivenss through X.
in
- 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/
| |