Re: [PATCH] 2.5.72 O(1) interactivity bugfix

From: Mike Galbraith (
Date: Thu Jun 19 2003 - 04:18:49 EST

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.



(messagus interruptus?)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

This archive was generated by hypermail 2b29 : Mon Jun 23 2003 - 22:00:29 EST