Re: 2.5.65-mm2

[Mike Galbraith <efault@gmx.de>]

At 07:36 AM 3/20/2003 -0700, Steven Cole wrote:
>On Wed, 2003-03-19 at 21:27, Ed Tomlinson wrote:
> > On March 19, 2003 06:45 pm, Steven P. Cole wrote:
> > > On Wed, 2003-03-19 at 17:33, Andrew Morton wrote:
> > > > "Steven P. Cole" <elenstev@mesatop.com> wrote:
> > > > > > Summary: using ext3, the simple window shake and scrollbar wiggle
> > > > > > tests were much improved, but really using Evolution left much 
> to be
> > > > > > desired.
> > > > >
> > > > > Replying to myself for a followup,
> > > > >
> > > > > I repeated the tests with 2.5.65-mm2 elevator=deadline and the
> > > > > situation was similar to elevator=as.  Running dbench on ext3, the
> > > > > response to desktop switches and window wiggles was improved over
> > > > > running dbench on reiserfs, but typing in Evolution was subject 
> to long
> > > > > delays with dbench clients greater than 16.
> > > >
> > > > OK, final question before I get off my butt and find a way to reproduce
> > > > this:
> > > >
> > > > Does reverting
> > > >
> > > > 
> http://www.zip.com.au/~akpm/linux/patches/2.5/2.5.65/2.5.65-mm2/broken-ou
> > > >t/sched-2.5.64-D3.patch
> > > >
> > > > help?
> > >
> > > Sorry, didn't have much time for a lot of testing, but no miracles
> > > occurred.  With 5 minutes of testing 2.5.65-mm2 and dbench 24 on ext3
> > > and that patch reverted (first hunk had to be manually fixed), I don't
> > > see any improvement.  Still the same long long delays in trying to use
> > > Evolution.
> >
> > Steven,
> >
> > Do things improve with the patch below applied?  You have to backout the
> > schedule-tuneables patch before appling it.
> >
> > Ed Tomlinson
>
>[patch snipped]
>
>I tried that patch, and the bad behavior with the Evolution "Compose a
>Message" window remains.  With a load of dbench 12, I had stalls of many
>seconds before I could type something.  Also, here is an additional
>symptom.  If I move the Evolution "Compose" window around rapidly, it
>leaves a smear of itself on the screen under itself.  With all -mm2
>variants, this smear stays for an intolerably long time (tens of
>seconds) while that window does not record keyboard strokes.  2.5.65-bk
>on the other hand exhibits much more benign behavior.

This is a side effect of Ingo's (nice!) latency change methinks.  When you 
have several cpu hogs running (dbench), and they are cleaning your cpu's 
clock by using their full bandwidth to attain maximum throughput, and they 
then break up their timeslice in order to provide you with more 
responsiveness, and then their _cumulative_  sleep time between (round 
robin!) cpu hard burns is added to their sleep_avg, (boy is this a long 
sentence) you will (likely) find that they run at a highly elevated 
priority and starve the devil out of everything else because they can not 
possibly get enough cpu to eat the sleep_avg they have been given (only way 
to reduce their priority without forking).  Virgin .65 is also subject to 
the positive feedback loop (irman's process load is worst case methinks, 
and rounding down only ~hides it).

I have a really horrid looking sched.c right now that works around some of 
this problem in disgusting ways.  If you want to try it, give me a holler 
before tomorrow morning (slice 'n dice resumes) and I'll rip it out and 
send it to you.  Fair warning though, if you have good taste, don't look at 
it at all before applying.  There are a few of spots I wouldn't even want 
to _try_ to justify.  I don't think dbench will be able to dork it up, but 
irman's process load (horrible thing) now can again.  (it's pure 
research... that says a lot;)

Bottom line is that once cpu hogs are falsely determined to be sleepers, 
positive feedback kills you.

         -Mike