Re: [PATCH] O3int interactivity for 2.5.74-mm2
Mike Galbraith (efault@gmx.de)
Mon, 07 Jul 2003 11:40:49 +0200
At 01:19 PM 7/7/2003 +1000, Con Kolivas wrote:
>On Mon, 7 Jul 2003 04:36, Felipe Alfaro Solana wrote:
> > On Sun, 2003-07-06 at 19:16, Con Kolivas wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Attached is an incremental patch against 2.5.74-mm2 with more
> > > interactivity work. Audio should be quite resistant to skips with this,
> > > and it should not induce further unfairness.
> > >
> > > Changes:
> > > The sleep_avg buffer was not needed with the improved semantics in O2int
> > > so it has been removed entirely as it created regressions in O2int.
> > >
> > > A small change to the idle detection code to only make tasks with enough
> > > accumulated sleep_avg become idle.
> > >
> > > Minor cleanups and clarified code.
> > >
> > >
> > > Other issues:
> > > Jerky mouse with heavy page rendering in web browsers remains. This is a
> > > different issue to the audio and will need some more thought.
> > >
> > > The patch is also available for download here:
> > > http://kernel.kolivas.org/2.5
> > >
> > > Note for those who wish to get smooth X desktop feel now for their own
> > > use, the granularity patch on that website will do wonders on top of
> > > O3int, but a different approach will be needed for mainstream
> > > consumption.
> >
> > I'm seeing extreme X starvation with this patch under 2.5.74-mm2 when
> > starting a CPU hogger:
> >
> > 1. Start a KDE session.
> > 2. Launch a Konsole
> > 3. Launch Konqueror
> > 4. Launch XMMS
> > 5. Make XMMS play an MP3 file
> > 6. On the Konsole terminal, run "while true; do a=2; done"
> >
> > When the "while..." is run, X starves completely for ~5 seconds (e.g.
> > the mouse cursor doesn't respond to my input events). After those 5
> > seconds, the mouse cursor goes jerky for a while (~2 seconds) and then
> > the system gets responsive.
>
>Aha!
>
>Thanks to Felipe who picked this up I was able to find the one bug causing me
>grief. The idle detection code was allowing the sleep_avg to get to
>ridiculously high levels. This is corrected in the following replacement
>O3int patch. Note this fixes the mozilla issue too. Kick arse!!
I took this out for a spin in stock 74. If I do while true; do sh -c 'ps l
$$'; date; sleep 1; done, the shell is running at priority 22. In the face
of any load, that leads to quite long response times. With a make -j5
bzImage running, I frequently saw response times of over a second. In X,
with a make -j2 bzImage running, opening a new shell takes too long, and X
loses interactive status considerably quicker than stock when doing window
wiggle. Init is at 20, and kernel threads bounce around between 15 and 20
depending on how active they are (doesn't seem good considering they're
using practically no cpu).
Thud is still dead, but maybe _too_ dead ;-) I never saw it get above the
lowest priority, which is very unfair considering the amount of sleeping it
does.
-Mike
-
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/