O6.1int

The bug in the O6int patch probably wasn't responsible for WIktor's problem actually. It shouldn't manifest for a very long time. Anyway here is the fix and a couple of minor cleanups.

@@ -78,7 +78,7 @@
 #define STARVATION_LIMIT	(10*HZ)
 #define SLEEP_BUFFER		(HZ/100)
 #define NODE_THRESHOLD		125
-#define MAX_BONUS		(40 * PRIO_BONUS_RATIO / 100)
+#define MAX_BONUS		(MAX_USER_PRIO * PRIO_BONUS_RATIO / 100)
 
 /*
  * If a task is 'interactive' then we reinsert it in the active

@@ -390,8 +390,6 @@ static inline void activate_task(task_t 
 	long sleep_time = jiffies - p->last_run - 1;
 
 	if (sleep_time > 0) {
-		unsigned long runtime = jiffies - p->avg_start;
-
 		/*
 		 * Tasks that sleep a long time are categorised as idle and
 		 * will get just under interactive status with a small runtime

@@ -402,6 +400,11 @@ static inline void activate_task(task_t 
 			p->sleep_avg = MIN_SLEEP_AVG * (MAX_BONUS - INTERACTIVE_DELTA - 2) /
 				MAX_BONUS;
 		} else {
+			unsigned long runtime = jiffies - p->avg_start;
+
+			if (runtime > MAX_SLEEP_AVG)
+				runtime = MAX_SLEEP_AVG;
+
 			/*
 			 * This code gives a bonus to interactive tasks.
 			 *

Thanks Con! Running the modified 06.1 patch now. With the previous patch I did notice a slowdown of X in general over time (slow repainting and such).

Lets see how this one goes...

This is even better than plain O6-int. Everything is nearly perfect. One thing I dislike a bit is that on my slow PIII 700Mhz, moving a medium-sized window over Evolution 1.4.3 main window (displaying my INBOX full of messages) makes the window movement a little jumpy (Evolution 1.4.3 is well-known to be a serious CPU hogger when repainting windows).

Renicing X to -20 helps a little with the jumpiness. Nice work, indeed!

Thanks. That one I _do_ know about, and am still thinking about a fair way to fix.

Con

About the same, actually. There are a few differences, but I can't call one better or worse.

In 2.6.0-test1, the cc1 processes hover around 30 (early on they're lower, but they ramp up quickly). Xmms stays fixed at 20 pretty much the entire time. X stays fixed at 15, though sometimes with heavy window moving it'll skyrocket to 16. :) Mozilla typically is at 20, but after lots of scrolling, it edges up slowly (and, I think, pretty linearly) to 30. Scrolling's bad by the time you get to 23 (with the compile going; if it's the only interesting thing happening, it's smooth all the way up).

The jerkiness in mozilla scrolling repeatedly takes three to four seconds before it shows up. Let it sit for a few more seconds and it's good to go again, at least for another three to four seconds.

The python process updating the portage database is in the 23-25 range.

In 2.6.0-test1-mm1 with O6.1int, mozilla takes longer to get jerky (15-20 seconds), but once it does, it gets stuck there pretty bad. Over the 16 minutes it took to compile the kernel, I think I managed to get it unstuck twice (maybe I didn't know how to do it right -- I kept poking at it and maybe that was the wrong thing to do). When left alone, it would settle at 24, though it would drop to 20 or 21 when either raised to the top of the window stack or lowered to the bottom (I'm using fvwm, in case that matters here). It would come back up to 24 within a second or two. Any scrolling instantly brought it up to 27 and climbing.

X, cc1, and xmms all had the same behavior as in vanilla (roughly the same amount of skippiness).

The python process had a lower priority, spending most of its time in the 17-20 range.

One other thing -- xmms skips seem to cause it to spit out

** WARNING **: snd_pcm_wait: Input/output error ** WARNING **: Buffer time reduced from 500 ms to 371 ms

Not consistently one or the other or both, but at least one of those would show up each time.

Hope this helps,
Danek

That's weird, unless you nice 5 them they shouldn't get any higher than 25. A quick code review doesn't reveal to me why that would be the case.

Also weird; it's almost impossible to get stuck at the static priority. 20 is what a nice 5 application would be.

Also sounds like nice 5

Same thing.

Same. (how >25 ?)

That's more consistent.

Not sure what these really mean.

Not entirely sure. I'll continue reviewing my code.

Con

<quote sender="Con Kolivas">

<snipped>

Conman,

Was running O6int, and after running my laptop for 1/2 day, I experienced obvious slowdown, and not just xmms is jittering, licq is not functioning smoothly, etc. Was running licq, xmms, couple of aterm, ssh. Prior to these, was running lmbench.

Now running O6.1int, no problem at the moment, but noticable improvement especially when hiding/unhiding aterm (using wmaker). Will keep you updated.

Specs:
CPU: Intel(R) Pentium(R) 4 Mobile CPU 1.60GHz stepping 04
Memory: 514732k/523776k available
Linux philyra 2.6.0-test1-mm1+o6int #1 Thu Jul 17 11:11:55 SGT 2003 i686

/amnesia

Perhaps he has PRIO_BONUS_RATIO set to 50.

-Mike

After fixing my nice +5 problem, I'm still seeing pretty much the same behavior, only with the priority values lowered by five. The entire desktop seems a bit snappier when not under load.

I got significantly more skipping in xmms under 2.6.0-test1 than under the O6.1 patch this time, rather than the two being seemingly the same. The scrolling behavior in mozilla was pretty much identical to how I described it before.

I did discover under O6.1int that I could make xmms block indefinitely when opening a window, with fvwm's wire frame manual placement, which I hadn't ever noticed before, but I'm not sure if that's because it actually wasn't there before, or I just placed the windows more quickly.

So, ultimately, no real difference.

Danek

The latter, I think. I had similar problems under kwin when moving windows with "display window contents while moving" unset. I don't seem to be able to reproduce it now (2.6.0-t1), though.

Rudo.

Side note i can actually wiggle a mozilla window around a 2000x2000@24bit display with make -j2 going and 'display window contents while moving' now in KDE3 w/ kwin. I normally have it on wireframe. X server is the XFree86 radeon driver w/ a 9100 and 128Mb of video memory, system is dual 400, 512Mb ram.

function.linuxpower.ca

This could be a result of fvwm grabbing the X server while the wireframe stuff is going on, and xmms being blocked trying to update the image on screen (think "scrolling song title" ;)

I'm pretty sure if you were really unlucky you could hit just the wrong timing with O6.1 which might do this. O7 I believe addresses this.

Con

Yah, I'm pretty sure that's what it is. I just tried it again, and I couldn't get it to happen again, but, like I'd expect, none of the graphics (anywhere on the screen) updated with the wireframe up. I'd guess xmms has some incorrect synchronization between its audio and display threads, and I just happened to be hitting that consistently last night, but not now.

Danek