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

[Nick Piggin]

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