Re: 2.5.65-mm2

["Steven P. Cole" <elenstev@mesatop.com>]

On Thu, 2003-03-20 at 12:48, Mike Galbraith wrote:
> 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 
> 
> 
Sure, either post a patch against a known sync point, .65, .65-bk, or
65-mm2, or send me the sched.c file itself (2600 lines might be a little
too much for the entire list).

If you send it in the next 2 hours, I can test today, otherwise I'll do
it manana.

Steven
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org">aart@kvack.org</a>