Messages in this thread | | | Date | Thu, 19 Jun 2003 11:18:49 +0200 | From | Mike Galbraith <> | Subject | Re: [PATCH] 2.5.72 O(1) interactivity bugfix |
| |
At 06:57 PM 6/19/2003 +1000, Nick Piggin wrote:
>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.
Yes. I was thinking about the wastage when I get bored and minimize or cover up eye-candy. For that kind of stuff, the existing scheduler syscalls would probably be much more efficient, because userland knows if I can see cpu oinker's output.
>>>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?
Exactly. That's what made backboost so wonderful... X/KDE wiggies boosted each other.
>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.
Yes.
>in
(messagus interruptus?)
-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/
| |