On Thu, 2003-03-20 at 12:48, Mike Galbraith wrote:

At 07:36 AM 3/20/2003 -0700, Steven Cole wrote:

quoted

On Wed, 2003-03-19 at 21:27, Ed Tomlinson wrote:

quoted

On March 19, 2003 06:45 pm, Steven P. Cole wrote:

quoted

On Wed, 2003-03-19 at 17:33, Andrew Morton wrote:

quoted

"Steven P. Cole" [off-list ref] wrote:

quoted

quoted

Summary: using ext3, the simple window shake and scrollbar wiggle
tests were much improved, but really using Evolution left much 

to be

quoted

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

quoted

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

quoted

quoted

quoted

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>