Re: 2.5.66-(bk) == horrible response times for non X11 applications

[Jakob Oestergaard <jakob@unthought.net>]

On Wed, Apr 09, 2003 at 10:01:09AM +0200, Helge Hafting wrote:
> Jakob Oestergaard wrote:
> >On Sun, Apr 06, 2003 at 06:24:35PM -0700, Andrew Morton wrote:
> [...]
> >>the problem with setiathome is that it displays something every now and
> >>then - so it gets a backboost from X, and hovers at a relatively high
> >>priority.
> >
> >
> >Why are niced processes boosted?   Does that make sense?
> >
> >If only non-niced processes were boosted, wouldn't that pretty much fix
> >the problem?
> >
> You'd have exactly the same problem for any non-niced cpu hog
> that displays something now and then. A non-niced cpu hog is supposed
> to be ok because the interactive processes are boosted above them.

A non-niced CPU hog that has interactivity, like eh, Descent or
Half-Life (under Wine) - well, I want those to get one heck of a lot
more boost than my seti...  or my emacs...

glxgears - if I run it (I don't know why I would, but let's say I wanted
to) - I don't want it to drop frames to favour my emacs or kword or
whatever (in the case of glxgears maybe I would - but I wouldn't run it
in the first place - let's just assume that glxgears is really some
important real-time visualization application).  If emacs behaves "less
interactively" than glxgears, then this is because glxgears is doing
something intensive, eg. it really gets hurt if it is not heavily
boosted.   Yes, you would be insane to run glxgears and some other
interactive application simultaneously, and expect that both can get 90%
of the resources - but this is the problem of limited resources and no
amount of cleverness is going to solve that.

> 
> Gui is becoming popular, so many compute tasks get some sort of
> display, even if it only is a progress bar.

And if they update the progress bar 100 times per second, then either it
is crucially important that this is not delayed, or the app needs
fixing.

You can break Linux in a million ways from user space by writing poor
user space code.

It wouldn't update 100 times per second unless it was important would
it?   And if it is important, then it's a lot better to make sure it
happens, than to ensure that the bash in the xterm next door gets it's
timeslices exactly when it wants them.   After all, you can type in a
laggy terminal (and if you type enough, it will get similar
interactiveness boost and we're back to the problem of limited
resources).

Look, I'm not trying to defend the boosting mechanism at all costs - I'm
just trying to argue that it's not fundamentally insane.   :)

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............: