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.
--- linux-2.6.0-test1-mm1/kernel/sched.c 2003-07-17 11:24:54.000000000 +1000
+++ linux-2.6.0-testck1/kernel/sched.c 2003-07-17 11:59:01.000000000 +1000
@@ -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.
*
Con Kolivas wrote:
> 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.
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...
On Thu, 2003-07-17 at 04:13, Con Kolivas wrote:
> 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.
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!
On Thu, 17 Jul 2003 17:45, Felipe Alfaro Solana wrote:
> On Thu, 2003-07-17 at 04:13, Con Kolivas wrote:
> > 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.
>
> 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).
Thanks. That one I _do_ know about, and am still thinking about a fair way to
fix.
Con
On Thu, Jul 17, 2003, Con Kolivas wrote:
> Thanks for testing. How does vanilla 2.6.0-test1 compare?
About the same, actually. There are a few differences, but I can't call
one better or worse.
> Can you watch top while all this is running, and see what dynamic
> priority these applications are during this (the cc's, X, mozilla,
> xterm and xmms), and when their behavious is less than ideal what the
> priority is.
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
On Thu, 17 Jul 2003 18:04, Danek Duvall wrote:
> In 2.6.0-test1, the cc1 processes hover around 30 (early on they're
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.
> 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
Also weird; it's almost impossible to get stuck at the static priority. 20 is
what a nice 5 application would be.
> window moving it'll skyrocket to 16. :) Mozilla typically is at 20,
Also sounds like nice 5
> 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
Same thing.
> 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.
Same. (how >25 ?)
>
> 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.
That's more consistent.
>
> 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.
Not sure what these really mean.
> Hope this helps,
Not entirely sure. I'll continue reviewing my code.
Con
<quote sender="Con Kolivas">
> On Thu, 17 Jul 2003 18:04, Danek Duvall wrote:
> > In 2.6.0-test1, the cc1 processes hover around 30 (early on they're
>
<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
At 06:21 PM 7/17/2003 +1000, Con Kolivas wrote:
>On Thu, 17 Jul 2003 18:04, Danek Duvall wrote:
> > In 2.6.0-test1, the cc1 processes hover around 30 (early on they're
>
>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.
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
> 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.
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.
On Fri, 18 Jul 2003, Rudo Thomas wrote:
> > 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.
>
> 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.
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
On Sat, 19 Jul 2003 00:43, [email protected] wrote:
> On Fri, 18 Jul 2003 00:07:49 PDT, Danek Duvall said:
> > 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.
>
> 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
[email protected] wrote:
> 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" ;)
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
On Fri, 18 Jul 2003 00:07:49 PDT, Danek Duvall said:
> 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.
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" ;)