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/
This archive was generated by hypermail 2b29 : Mon Jun 23 2003 - 22:00:29 EST