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

[Nick Piggin <piggin@cyberone.com.au>]

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.


Soundcard even...