-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Attached is an incremental patch against 2.5.74-mm2 with more interactivity
work. Audio should be quite resistant to skips with this, and it should not
induce further unfairness.
Changes:
The sleep_avg buffer was not needed with the improved semantics in O2int so it
has been removed entirely as it created regressions in O2int.
A small change to the idle detection code to only make tasks with enough
accumulated sleep_avg become idle.
Minor cleanups and clarified code.
Other issues:
Jerky mouse with heavy page rendering in web browsers remains. This is a
different issue to the audio and will need some more thought.
The patch is also available for download here:
http://kernel.kolivas.org/2.5
Note for those who wish to get smooth X desktop feel now for their own use,
the granularity patch on that website will do wonders on top of O3int, but a
different approach will be needed for mainstream consumption.
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/CFmHF6dfvkL3i1gRAkqTAKCjE3lRwBWomZbn/asWtv+OWiFovQCfZo0P
UfqOKVgv88faks6+vPq5BGM=
=ZR4Y
-----END PGP SIGNATURE-----
On Sun, 2003-07-06 at 19:16, Con Kolivas wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Attached is an incremental patch against 2.5.74-mm2 with more interactivity
> work. Audio should be quite resistant to skips with this, and it should not
> induce further unfairness.
>
> Changes:
> The sleep_avg buffer was not needed with the improved semantics in O2int so it
> has been removed entirely as it created regressions in O2int.
>
> A small change to the idle detection code to only make tasks with enough
> accumulated sleep_avg become idle.
>
> Minor cleanups and clarified code.
>
>
> Other issues:
> Jerky mouse with heavy page rendering in web browsers remains. This is a
> different issue to the audio and will need some more thought.
>
> The patch is also available for download here:
> http://kernel.kolivas.org/2.5
>
> Note for those who wish to get smooth X desktop feel now for their own use,
> the granularity patch on that website will do wonders on top of O3int, but a
> different approach will be needed for mainstream consumption.
I'm seeing extreme X starvation with this patch under 2.5.74-mm2 when
starting a CPU hogger:
1. Start a KDE session.
2. Launch a Konsole
3. Launch Konqueror
4. Launch XMMS
5. Make XMMS play an MP3 file
6. On the Konsole terminal, run "while true; do a=2; done"
When the "while..." is run, X starves completely for ~5 seconds (e.g.
the mouse cursor doesn't respond to my input events). After those 5
seconds, the mouse cursor goes jerky for a while (~2 seconds) and then
the system gets responsive.
PS: There are no user processes reniced.
On Mon, 7 Jul 2003 04:36, Felipe Alfaro Solana wrote:
> On Sun, 2003-07-06 at 19:16, Con Kolivas wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Attached is an incremental patch against 2.5.74-mm2 with more
> > interactivity work. Audio should be quite resistant to skips with this,
> > and it should not induce further unfairness.
> >
> > Changes:
> > The sleep_avg buffer was not needed with the improved semantics in O2int
> > so it has been removed entirely as it created regressions in O2int.
> >
> > A small change to the idle detection code to only make tasks with enough
> > accumulated sleep_avg become idle.
> >
> > Minor cleanups and clarified code.
> >
> >
> > Other issues:
> > Jerky mouse with heavy page rendering in web browsers remains. This is a
> > different issue to the audio and will need some more thought.
> >
> > The patch is also available for download here:
> > http://kernel.kolivas.org/2.5
> >
> > Note for those who wish to get smooth X desktop feel now for their own
> > use, the granularity patch on that website will do wonders on top of
> > O3int, but a different approach will be needed for mainstream
> > consumption.
>
> I'm seeing extreme X starvation with this patch under 2.5.74-mm2 when
> starting a CPU hogger:
>
> 1. Start a KDE session.
> 2. Launch a Konsole
> 3. Launch Konqueror
> 4. Launch XMMS
> 5. Make XMMS play an MP3 file
> 6. On the Konsole terminal, run "while true; do a=2; done"
>
> When the "while..." is run, X starves completely for ~5 seconds (e.g.
> the mouse cursor doesn't respond to my input events). After those 5
> seconds, the mouse cursor goes jerky for a while (~2 seconds) and then
> the system gets responsive.
Cool you beat the idle detection code. Leave the konsole for just a few
seconds before trying this and see if it's any different. Having not slept
because of this patch and now going to work I think it can wait a little
before I work on it any more.
Con
On Mon, 7 Jul 2003 04:36, Felipe Alfaro Solana wrote:
> On Sun, 2003-07-06 at 19:16, Con Kolivas wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Attached is an incremental patch against 2.5.74-mm2 with more
> > interactivity work. Audio should be quite resistant to skips with this,
> > and it should not induce further unfairness.
> >
> > Changes:
> > The sleep_avg buffer was not needed with the improved semantics in O2int
> > so it has been removed entirely as it created regressions in O2int.
> >
> > A small change to the idle detection code to only make tasks with enough
> > accumulated sleep_avg become idle.
> >
> > Minor cleanups and clarified code.
> >
> >
> > Other issues:
> > Jerky mouse with heavy page rendering in web browsers remains. This is a
> > different issue to the audio and will need some more thought.
> >
> > The patch is also available for download here:
> > http://kernel.kolivas.org/2.5
> >
> > Note for those who wish to get smooth X desktop feel now for their own
> > use, the granularity patch on that website will do wonders on top of
> > O3int, but a different approach will be needed for mainstream
> > consumption.
>
> I'm seeing extreme X starvation with this patch under 2.5.74-mm2 when
> starting a CPU hogger:
>
> 1. Start a KDE session.
> 2. Launch a Konsole
> 3. Launch Konqueror
> 4. Launch XMMS
> 5. Make XMMS play an MP3 file
> 6. On the Konsole terminal, run "while true; do a=2; done"
>
> When the "while..." is run, X starves completely for ~5 seconds (e.g.
> the mouse cursor doesn't respond to my input events). After those 5
> seconds, the mouse cursor goes jerky for a while (~2 seconds) and then
> the system gets responsive.
Oh one more thing if you dare. Try commenting out these lines in sched.c ~650:
normalise_sleep(p);
normalise_sleep(p->parent);
if (p->sleep_avg < p->parent->sleep_avg)
p->parent->sleep_avg = (p->parent->sleep_avg * EXIT_WEIGHT +
p->sleep_avg) / (EXIT_WEIGHT + 1);
Con
On Mon, 7 Jul 2003 04:36, Felipe Alfaro Solana wrote:
> On Sun, 2003-07-06 at 19:16, Con Kolivas wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Attached is an incremental patch against 2.5.74-mm2 with more
> > interactivity work. Audio should be quite resistant to skips with this,
> > and it should not induce further unfairness.
> >
> > Changes:
> > The sleep_avg buffer was not needed with the improved semantics in O2int
> > so it has been removed entirely as it created regressions in O2int.
> >
> > A small change to the idle detection code to only make tasks with enough
> > accumulated sleep_avg become idle.
> >
> > Minor cleanups and clarified code.
> >
> >
> > Other issues:
> > Jerky mouse with heavy page rendering in web browsers remains. This is a
> > different issue to the audio and will need some more thought.
> >
> > The patch is also available for download here:
> > http://kernel.kolivas.org/2.5
> >
> > Note for those who wish to get smooth X desktop feel now for their own
> > use, the granularity patch on that website will do wonders on top of
> > O3int, but a different approach will be needed for mainstream
> > consumption.
>
> I'm seeing extreme X starvation with this patch under 2.5.74-mm2 when
> starting a CPU hogger:
>
> 1. Start a KDE session.
> 2. Launch a Konsole
> 3. Launch Konqueror
> 4. Launch XMMS
> 5. Make XMMS play an MP3 file
> 6. On the Konsole terminal, run "while true; do a=2; done"
>
> When the "while..." is run, X starves completely for ~5 seconds (e.g.
> the mouse cursor doesn't respond to my input events). After those 5
> seconds, the mouse cursor goes jerky for a while (~2 seconds) and then
> the system gets responsive.
Aha!
Thanks to Felipe who picked this up I was able to find the one bug causing me
grief. The idle detection code was allowing the sleep_avg to get to
ridiculously high levels. This is corrected in the following replacement
O3int patch. Note this fixes the mozilla issue too. Kick arse!!
Con
On Mon, 2003-07-07 at 05:19, Con Kolivas wrote:
> On Mon, 7 Jul 2003 04:36, Felipe Alfaro Solana wrote:
> > I'm seeing extreme X starvation with this patch under 2.5.74-mm2 when
> > starting a CPU hogger:
> >
> > 1. Start a KDE session.
> > 2. Launch a Konsole
> > 3. Launch Konqueror
> > 4. Launch XMMS
> > 5. Make XMMS play an MP3 file
> > 6. On the Konsole terminal, run "while true; do a=2; done"
> >
> > When the "while..." is run, X starves completely for ~5 seconds (e.g.
> > the mouse cursor doesn't respond to my input events). After those 5
> > seconds, the mouse cursor goes jerky for a while (~2 seconds) and then
> > the system gets responsive.
>
> Aha!
>
> Thanks to Felipe who picked this up I was able to find the one bug causing me
> grief. The idle detection code was allowing the sleep_avg to get to
> ridiculously high levels. This is corrected in the following replacement
> O3int patch. Note this fixes the mozilla issue too. Kick arse!!
Yeah! I can't reproduce the bug anymore :-) Good work!
Is there any tunable to make the scheduler adjust the interactivity/CPU
usage a little bit faster? Just after launching XMMS and make it play,
moving the Konqueror window like crazy makes XMMS skip for a few
seconds.
At 01:19 PM 7/7/2003 +1000, Con Kolivas wrote:
>On Mon, 7 Jul 2003 04:36, Felipe Alfaro Solana wrote:
> > On Sun, 2003-07-06 at 19:16, Con Kolivas wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Attached is an incremental patch against 2.5.74-mm2 with more
> > > interactivity work. Audio should be quite resistant to skips with this,
> > > and it should not induce further unfairness.
> > >
> > > Changes:
> > > The sleep_avg buffer was not needed with the improved semantics in O2int
> > > so it has been removed entirely as it created regressions in O2int.
> > >
> > > A small change to the idle detection code to only make tasks with enough
> > > accumulated sleep_avg become idle.
> > >
> > > Minor cleanups and clarified code.
> > >
> > >
> > > Other issues:
> > > Jerky mouse with heavy page rendering in web browsers remains. This is a
> > > different issue to the audio and will need some more thought.
> > >
> > > The patch is also available for download here:
> > > http://kernel.kolivas.org/2.5
> > >
> > > Note for those who wish to get smooth X desktop feel now for their own
> > > use, the granularity patch on that website will do wonders on top of
> > > O3int, but a different approach will be needed for mainstream
> > > consumption.
> >
> > I'm seeing extreme X starvation with this patch under 2.5.74-mm2 when
> > starting a CPU hogger:
> >
> > 1. Start a KDE session.
> > 2. Launch a Konsole
> > 3. Launch Konqueror
> > 4. Launch XMMS
> > 5. Make XMMS play an MP3 file
> > 6. On the Konsole terminal, run "while true; do a=2; done"
> >
> > When the "while..." is run, X starves completely for ~5 seconds (e.g.
> > the mouse cursor doesn't respond to my input events). After those 5
> > seconds, the mouse cursor goes jerky for a while (~2 seconds) and then
> > the system gets responsive.
>
>Aha!
>
>Thanks to Felipe who picked this up I was able to find the one bug causing me
>grief. The idle detection code was allowing the sleep_avg to get to
>ridiculously high levels. This is corrected in the following replacement
>O3int patch. Note this fixes the mozilla issue too. Kick arse!!
I took this out for a spin in stock 74. If I do while true; do sh -c 'ps l
$$'; date; sleep 1; done, the shell is running at priority 22. In the face
of any load, that leads to quite long response times. With a make -j5
bzImage running, I frequently saw response times of over a second. In X,
with a make -j2 bzImage running, opening a new shell takes too long, and X
loses interactive status considerably quicker than stock when doing window
wiggle. Init is at 20, and kernel threads bounce around between 15 and 20
depending on how active they are (doesn't seem good considering they're
using practically no cpu).
Thud is still dead, but maybe _too_ dead ;-) I never saw it get above the
lowest priority, which is very unfair considering the amount of sleeping it
does.
-Mike
On Mon, 7 Jul 2003 19:40, Mike Galbraith wrote:
> At 01:19 PM 7/7/2003 +1000, Con Kolivas wrote:
> >Thanks to Felipe who picked this up I was able to find the one bug causing
> > me grief. The idle detection code was allowing the sleep_avg to get to
> > ridiculously high levels. This is corrected in the following replacement
> > O3int patch. Note this fixes the mozilla issue too. Kick arse!!
>
> I took this out for a spin in stock 74. If I do while true; do sh -c 'ps l
> $$'; date; sleep 1; done, the shell is running at priority 22. In the face
You're hitting spot on the idle detection code. Sleep for a second or longer
and this patch makes you get only your static priority. This way if you
suddenly become a cpu hog you cant starve the machine. ie. it works with your
test exactly as I planned it.
> of any load, that leads to quite long response times. With a make -j5
> bzImage running, I frequently saw response times of over a second. In X,
> with a make -j2 bzImage running, opening a new shell takes too long, and X
Yes I was planning on increasing the child penalty to 95 once the other things
settled down. This will speed up start time.
> loses interactive status considerably quicker than stock when doing window
The sleep avg decrements at the same place and at the same rate in my patch as
it does in stock, so I can't see how that's happening.
> wiggle. Init is at 20, and kernel threads bounce around between 15 and 20
> depending on how active they are (doesn't seem good considering they're
> using practically no cpu).
They're idle. Why do they need higher priority?
> Thud is still dead, but maybe _too_ dead ;-) I never saw it get above the
> lowest priority, which is very unfair considering the amount of sleeping it
> does.
It sounds like you're applying your idea of what you expect the priority to be
based on previous algorithms rather than judging it on it's own merits. I
didn't see any mention of whether audio skips less or mouse moves smoother
which is what it's addressing. The data shows it doesn't unfairly
disadvantage other tasks. CPU hogs get treated as such.
Con
>
> Aha!
>
> Thanks to Felipe who picked this up I was able to find the one bug causing
> me grief. The idle detection code was allowing the sleep_avg to get to
> ridiculously high levels. This is corrected in the following replacement
> O3int patch. Note this fixes the mozilla issue too. Kick arse!!
>
> Con
Just booted with patch-O3int-0307071315 on top of 2.5.74-mm2 and the mouse
stuttering under high CPU load has gone and no audio skipping.
Truly brilliant work
Thank you
Nick
On Monday 07 July 2003 12:51, Nick Sanders wrote:
Hi Con, Hi Andrew,
> > Thanks to Felipe who picked this up I was able to find the one bug
> > causing me grief. The idle detection code was allowing the sleep_avg to
> > get to ridiculously high levels. This is corrected in the following
> > replacement O3int patch. Note this fixes the mozilla issue too. Kick
> > arse!!
> Just booted with patch-O3int-0307071315 on top of 2.5.74-mm2 and the mouse
> stuttering under high CPU load has gone and no audio skipping.
> Truly brilliant work
> Thank you
> Nick
Hmm, this becomes better and better, but it's still not perfect [tm].
- An Xterm needs ~30 seconds to open up while "make -j16 bzImage modules"
- An Xterm needs ~15 seconds to open up while "make -j8 bzImage modules"
- XMMS does _not_ skip mp3's while above.
- Kmail is almost unusable while above (stops for about 5 secs every 15-20
secs). KMail is also very slow while the machine is doing nothing.
- X runs with nice 0, prio 15 (nice -11 is prio 4, does not make difference)
Over all, the whole system seems in a ~snail mode.
Andrew, two things:
1. I'll test it with high job numbers, because it _must_ be possible to use
that w/o any stops of xmms music, w/o X running like a dog etc.
2. I use anticipatory scheduler for sure. Best I've ever seen, never had
any problems. :)
ciao, Marc
On Mon, 7 Jul 2003 22:19, Marc-Christian Petersen wrote:
> On Monday 07 July 2003 12:51, Nick Sanders wrote:
>
> Hi Con, Hi Andrew,
>
> > > Thanks to Felipe who picked this up I was able to find the one bug
> > > causing me grief. The idle detection code was allowing the sleep_avg to
> > > get to ridiculously high levels. This is corrected in the following
> > > replacement O3int patch. Note this fixes the mozilla issue too. Kick
> > > arse!!
> >
> > Just booted with patch-O3int-0307071315 on top of 2.5.74-mm2 and the
> > mouse stuttering under high CPU load has gone and no audio skipping.
> > Truly brilliant work
> > Thank you
> > Nick
>
> Hmm, this becomes better and better, but it's still not perfect [tm].
Thanks for feedback. I will keep working on it while I still have ideas and
direction based on the feedback.
> - An Xterm needs ~30 seconds to open up while "make -j16 bzImage modules"
> - An Xterm needs ~15 seconds to open up while "make -j8 bzImage modules"
> - XMMS does _not_ skip mp3's while above.
> - Kmail is almost unusable while above (stops for about 5 secs every 15-20
> secs). KMail is also very slow while the machine is doing nothing.
> - X runs with nice 0, prio 15 (nice -11 is prio 4, does not make
> difference)
Noted; and considered the next major hurdle (was also the most notable
complaint from Mike).
Con
I tried this one and it looks fine.
Big latex jobs are no longer noticeable when I play
xgalaga waiting for them to finish. I have
to look at the load meter now!
Helge Hafting
At 08:25 PM 7/7/2003 +1000, Con Kolivas wrote:
>On Mon, 7 Jul 2003 19:40, Mike Galbraith wrote:
> > At 01:19 PM 7/7/2003 +1000, Con Kolivas wrote:
> > >Thanks to Felipe who picked this up I was able to find the one bug causing
> > > me grief. The idle detection code was allowing the sleep_avg to get to
> > > ridiculously high levels. This is corrected in the following replacement
> > > O3int patch. Note this fixes the mozilla issue too. Kick arse!!
> >
> > I took this out for a spin in stock 74. If I do while true; do sh -c 'ps l
> > $$'; date; sleep 1; done, the shell is running at priority 22. In the face
>
>You're hitting spot on the idle detection code. Sleep for a second or longer
>and this patch makes you get only your static priority. This way if you
>suddenly become a cpu hog you cant starve the machine. ie. it works with your
>test exactly as I planned it.
That one is a definite regression in my book.
> > of any load, that leads to quite long response times. With a make -j5
> > bzImage running, I frequently saw response times of over a second. In X,
> > with a make -j2 bzImage running, opening a new shell takes too long, and X
>
>Yes I was planning on increasing the child penalty to 95 once the other
>things
>settled down. This will speed up start time.
>
> > loses interactive status considerably quicker than stock when doing window
>
>The sleep avg decrements at the same place and at the same rate in my
>patch as
>it does in stock, so I can't see how that's happening.
(dunno, just an observation)
> > wiggle. Init is at 20, and kernel threads bounce around between 15 and 20
> > depending on how active they are (doesn't seem good considering they're
> > using practically no cpu).
>
>They're idle. Why do they need higher priority?
So they can preempt the waker? kswapd doesn't need to be sitting around
twiddling it's thumbs after somebody wakes it up, it needs to start working
right now. The same for all of it's buddies. These guys don't need their
priorities being bounced around.
> > Thud is still dead, but maybe _too_ dead ;-) I never saw it get above the
> > lowest priority, which is very unfair considering the amount of sleeping it
> > does.
>
>It sounds like you're applying your idea of what you expect the priority
>to be
>based on previous algorithms rather than judging it on it's own merits. I
Perhaps, but I don't think so... see below.
>didn't see any mention of whether audio skips less or mouse moves smoother
>which is what it's addressing.
You have enough folks testing sound and whatnot. I'm commenting on general
effects that poked me in the eye during "take it for a spin around the
block" session.
> The data shows it doesn't unfairly
That's contest data right? Contest doesn't have any bursty loads that I
know of...
> disadvantage other tasks. CPU hogs get treated as such.
...and given the scheduler's reaction to thud, I can only assume (yeah, I
know;) that a bursty load will suffer in the presence of a sustained
runner. If you treat all cpu hungry loads the same, you may as well switch
to two priorities, interactive and not interactive no? That's what I meant
by too dead.
-Mike
On Tue, 8 Jul 2003 00:06, Mike Galbraith wrote:
> At 08:25 PM 7/7/2003 +1000, Con Kolivas wrote:
> >On Mon, 7 Jul 2003 19:40, Mike Galbraith wrote:
> > > At 01:19 PM 7/7/2003 +1000, Con Kolivas wrote:
> > > >Thanks to Felipe who picked this up I was able to find the one bug
> > > > causing me grief. The idle detection code was allowing the sleep_avg
> > > > to get to ridiculously high levels. This is corrected in the
> > > > following replacement O3int patch. Note this fixes the mozilla issue
> > > > too. Kick arse!!
> > >
> > > I took this out for a spin in stock 74. If I do while true; do sh -c
> > > 'ps l $$'; date; sleep 1; done, the shell is running at priority 22.
> > > In the face
> >
> >You're hitting spot on the idle detection code. Sleep for a second or
> > longer and this patch makes you get only your static priority. This way
> > if you suddenly become a cpu hog you cant starve the machine. ie. it
> > works with your test exactly as I planned it.
>
> That one is a definite regression in my book.
>
> > > of any load, that leads to quite long response times. With a make -j5
> > > bzImage running, I frequently saw response times of over a second. In
> > > X, with a make -j2 bzImage running, opening a new shell takes too long,
> > > and X
> >
> >Yes I was planning on increasing the child penalty to 95 once the other
> >things
> >settled down. This will speed up start time.
> >
> > > loses interactive status considerably quicker than stock when doing
> > > window
> >
> >The sleep avg decrements at the same place and at the same rate in my
> >patch as
> >it does in stock, so I can't see how that's happening.
>
> (dunno, just an observation)
>
> > > wiggle. Init is at 20, and kernel threads bounce around between 15 and
> > > 20 depending on how active they are (doesn't seem good considering
> > > they're using practically no cpu).
> >
> >They're idle. Why do they need higher priority?
>
> So they can preempt the waker? kswapd doesn't need to be sitting around
> twiddling it's thumbs after somebody wakes it up, it needs to start working
> right now. The same for all of it's buddies. These guys don't need their
> priorities being bounced around.
>
> > > Thud is still dead, but maybe _too_ dead ;-) I never saw it get above
> > > the lowest priority, which is very unfair considering the amount of
> > > sleeping it does.
> >
> >It sounds like you're applying your idea of what you expect the priority
> >to be
> >based on previous algorithms rather than judging it on it's own merits. I
>
> Perhaps, but I don't think so... see below.
>
> >didn't see any mention of whether audio skips less or mouse moves smoother
> >which is what it's addressing.
>
> You have enough folks testing sound and whatnot. I'm commenting on general
> effects that poked me in the eye during "take it for a spin around the
> block" session.
>
> > The data shows it doesn't unfairly
>
> That's contest data right? Contest doesn't have any bursty loads that I
> know of...
>
> > disadvantage other tasks. CPU hogs get treated as such.
>
> ...and given the scheduler's reaction to thud, I can only assume (yeah, I
> know;) that a bursty load will suffer in the presence of a sustained
> runner. If you treat all cpu hungry loads the same, you may as well switch
> to two priorities, interactive and not interactive no? That's what I meant
> by too dead.
Thanks for all these comments. Will try to consider them in further
development.
Con
On Mon, 7 Jul 2003, Marc-Christian Petersen wrote:
> On Monday 07 July 2003 12:51, Nick Sanders wrote:
>
> - An Xterm needs ~30 seconds to open up while "make -j16 bzImage modules"
> - An Xterm needs ~15 seconds to open up while "make -j8 bzImage modules"
> - XMMS does _not_ skip mp3's while above.
How fast is your box? RAM? disks? I'm personally more interested in 1-2
make -j2 bzImage going
> - Kmail is almost unusable while above (stops for about 5 secs every 15-20
> secs). KMail is also very slow while the machine is doing nothing.
> - X runs with nice 0, prio 15 (nice -11 is prio 4, does not make difference)
Looking at above load i'm not entirely surprised, but i presume you're
going to name a kernel which can handle that and still complete the builds
withing a sane time frame.
--
function.linuxpower.ca
Con Kolivas, Mon, Jul 07, 2003 05:19:57 +0200:
> > > Attached is an incremental patch against 2.5.74-mm2 with more
> > > interactivity work. Audio should be quite resistant to skips with this,
> > > and it should not induce further unfairness.
> > >
> > I'm seeing extreme X starvation with this patch under 2.5.74-mm2 when
> > starting a CPU hogger:
> >
>
> Thanks to Felipe who picked this up I was able to find the one bug causing me
> grief. The idle detection code was allowing the sleep_avg to get to
> ridiculously high levels. This is corrected in the following replacement
> O3int patch. Note this fixes the mozilla issue too. Kick arse!!
>
still skips. Pan, updating list of newsgroups, VIM compilation and xmms.
Con Kolivas said:
>
> Thanks to Felipe who picked this up I was able to find the one bug
> causing me grief. The idle detection code was allowing the sleep_avg to
> get to ridiculously high levels. This is corrected in the following
> replacement O3int patch. Note this fixes the mozilla issue too. Kick
> arse!!
>
> Con
Not really.
No change on my system.
No fancy gui (just fvwm). Testing is very simple:
In one xterm window make bzImage
in other mplayer /some/movie.avi
... and the movie is jerky :-(
In the weekend i did some experiments with the defines in kernel/sched.c
It seems that changing in MAX_TIMESLICE the "200" to "100" or even "50"
helps a little bit. (i was able to do a make bzImage and watch a movie
without noticing that is a kernel compile in background)
system is AMD DURON chipset via KT/KM 133, Ati Radeon VE.
I remeber with nostalgicaly about the times when i could (with a 2.5
kernel) do a make -j 5 bzImage AND watch a movie in the same time
--
# fortune
fortune: write error on /dev/null -- please empty the bit bucket
-----------------------------------------
This email was sent using SquirrelMail.
"Webmail for nuts!"
http://squirrelmail.org/
On Tue, 8 Jul 2003, Szonyi Calin wrote:
> In the weekend i did some experiments with the defines in kernel/sched.c
> It seems that changing in MAX_TIMESLICE the "200" to "100" or even "50"
> helps a little bit. (i was able to do a make bzImage and watch a movie
> without noticing that is a kernel compile in background)
I bet it helps. Something around 100-120 should be fine. Now we need an
exponential function of the priority to assign timeslices to try to
maintain interactivity. This should work :
#define TSDELTA (MAX_TIMESLICE - MIN_TIMESLICE)
#define KTSNORM (TSDELTA * TSDELTA * TSDELTA)
time_slice = MIN_TIMESLICE + (TSDELTA * prio * prio * prio) / KTSNORM;
Or something like :
static const short tsmap[] = {
10, 10, 10, 10, 10, 10, 10, 10, 10, 11,
11, 12, 13, 14, 15, 16, 17, 19, 20, 22,
24, 27, 29, 32, 35, 38, 42, 46, 50, 55,
60, 65, 70, 76, 82, 89, 96, 103, 111, 120,
};
This is a simple cubic, while a quadratic map looks like :
static const short tsmap[] = {
10, 10, 10, 10, 11, 11, 12, 13, 14, 15,
17, 18, 20, 22, 24, 26, 28, 30, 33, 36,
38, 41, 45, 48, 51, 55, 58, 62, 66, 70,
75, 79, 84, 88, 93, 98, 103, 109, 114, 120,
};
- Davide
On Tue, 8 Jul 2003 17:46, Davide Libenzi wrote:
> On Tue, 8 Jul 2003, Szonyi Calin wrote:
> > In the weekend i did some experiments with the defines in kernel/sched.c
> > It seems that changing in MAX_TIMESLICE the "200" to "100" or even "50"
> > helps a little bit. (i was able to do a make bzImage and watch a movie
> > without noticing that is a kernel compile in background)
>
> I bet it helps. Something around 100-120 should be fine. Now we need an
> exponential function of the priority to assign timeslices to try to
> maintain interactivity. This should work :
This is still decreasing the timeslices. Whether you do it linearly or
exponentially the timeslices are smaller, which just about everyone will
resist you doing.
Con
On Tue, 8 Jul 2003 17:11, Szonyi Calin wrote:
> Con Kolivas said:
> > Thanks to Felipe who picked this up I was able to find the one bug
> > causing me grief. The idle detection code was allowing the sleep_avg to
> > get to ridiculously high levels. This is corrected in the following
> > replacement O3int patch. Note this fixes the mozilla issue too. Kick
> > arse!!
> >
> > Con
>
> Not really.
Ok kick my butt instead so I can try and fix it.
> No change on my system.
> No fancy gui (just fvwm). Testing is very simple:
> In one xterm window make bzImage
> in other mplayer /some/movie.avi
> ... and the movie is jerky :-(
Can you tell me how it compares to vanilla at all, and can you watch top and
see what dynamic priorities are reported for the cc and mplayer processes
while it's running?
>
> In the weekend i did some experiments with the defines in kernel/sched.c
> It seems that changing in MAX_TIMESLICE the "200" to "100" or even "50"
> helps a little bit. (i was able to do a make bzImage and watch a movie
> without noticing that is a kernel compile in background)
Strong resistance to dropping the timeslices will remain. If you want to do
this, try adding the granularity patch instead which works better. Neither
will become mainline changes I'm afraid.
>
> system is AMD DURON chipset via KT/KM 133, Ati Radeon VE.
>
> I remeber with nostalgicaly about the times when i could (with a 2.5
> kernel) do a make -j 5 bzImage AND watch a movie in the same time
<sigh> If it were still the case I wouldn't be spending hundreds of hours
doing this :|
Con
On Tue, 8 Jul 2003, Con Kolivas wrote:
> On Tue, 8 Jul 2003 17:46, Davide Libenzi wrote:
> > On Tue, 8 Jul 2003, Szonyi Calin wrote:
> > > In the weekend i did some experiments with the defines in kernel/sched.c
> > > It seems that changing in MAX_TIMESLICE the "200" to "100" or even "50"
> > > helps a little bit. (i was able to do a make bzImage and watch a movie
> > > without noticing that is a kernel compile in background)
> >
> > I bet it helps. Something around 100-120 should be fine. Now we need an
> > exponential function of the priority to assign timeslices to try to
> > maintain interactivity. This should work :
>
> This is still decreasing the timeslices. Whether you do it linearly or
> exponentially the timeslices are smaller, which just about everyone will
> resist you doing.
Maybe you (and this Mr Everyone) might be interested in knowing that the
interactivity is not given by the absolute length of the timeslice but by
the ratio between timeslices. If you have three processes running with
timeslices :
A = 400
B = 200
C = 100
the interactivity is the same of the one if you have :
A = 100
B = 50
C = 25
What changes is the maxiomum CPU blackout time that each task has to see
before re-emerging again from the expired array. In the first case in
"only" 700ms while in the first case is 175ms.
- Davide
On Wed, 9 Jul 2003 01:12, Davide Libenzi wrote:
> On Tue, 8 Jul 2003, Con Kolivas wrote:
> > On Tue, 8 Jul 2003 17:46, Davide Libenzi wrote:
> > > On Tue, 8 Jul 2003, Szonyi Calin wrote:
> > > > In the weekend i did some experiments with the defines in
> > > > kernel/sched.c It seems that changing in MAX_TIMESLICE the "200" to
> > > > "100" or even "50" helps a little bit. (i was able to do a make
> > > > bzImage and watch a movie without noticing that is a kernel compile
> > > > in background)
> > >
> > > I bet it helps. Something around 100-120 should be fine. Now we need an
> > > exponential function of the priority to assign timeslices to try to
> > > maintain interactivity. This should work :
> >
> > This is still decreasing the timeslices. Whether you do it linearly or
> > exponentially the timeslices are smaller, which just about everyone will
> > resist you doing.
>
> Maybe you (and this Mr Everyone) might be interested in knowing that the
> interactivity is not given by the absolute length of the timeslice but by
> the ratio between timeslices. If you have three processes running with
> timeslices :
>
> A = 400
> B = 200
> C = 100
>
> the interactivity is the same of the one if you have :
>
> A = 100
> B = 50
> C = 25
>
> What changes is the maxiomum CPU blackout time that each task has to see
> before re-emerging again from the expired array. In the first case in
> "only" 700ms while in the first case is 175ms.
and what happens to the throughput?
On Wed, 9 Jul 2003, Con Kolivas wrote:
> > the ratio between timeslices. If you have three processes running with
> > timeslices :
> >
> > A = 400
> > B = 200
> > C = 100
> >
> > the interactivity is the same of the one if you have :
> >
> > A = 100
> > B = 50
> > C = 25
> >
> > What changes is the maxiomum CPU blackout time that each task has to see
> > before re-emerging again from the expired array. In the first case in
> > "only" 700ms while in the first case is 175ms.
>
> and what happens to the throughput?
Nothing. You'll have more context switches in average but if you think
that the context switch time will be diluted in tenths on ms runs you'll
get nothing. I really don't like to talk w/out being backed up by numbers
but currently I am really overbooked with other tasks and I cannot follow
up this (even if I'd like to). I am currently working 12-14 hours/day on
average, and I am one of those unperfect machines that still needs 6-7
hours rest somewhere during the day :)
(but I'll do it later if Ingo does not return from Mars or if someone else
does not do it)
- Davide
On Tuesday 08 July 2003 02:31, Zwane Mwaikambo wrote:
Hi Zwane,
> > - An Xterm needs ~30 seconds to open up while "make -j16 bzImage modules"
> > - An Xterm needs ~15 seconds to open up while "make -j8 bzImage modules"
> > - XMMS does _not_ skip mp3's while above.
> How fast is your box? RAM? disks? I'm personally more interested in 1-2
> make -j2 bzImage going
- Celeron 1,3GHz
- 512MB RAM
- 1GB SWAP (2 IDE disks, ~512MB on each disk)
- ATA100 Maxtor 60GB HDD
- ATA100 Fujitsu 40GB
Now I am running 2.5.74-mm3, xterm needs about 5 seconds to open up, but the
whole system is again in a snail mode. XMMS does not skip.
> > - Kmail is almost unusable while above (stops for about 5 secs every
> > 15-20 secs). KMail is also very slow while the machine is doing nothing.
> > - X runs with nice 0, prio 15 (nice -11 is prio 4, does not make
> > difference)
> Looking at above load i'm not entirely surprised, but i presume you're
> going to name a kernel which can handle that and still complete the builds
> withing a sane time frame.
For example, my wolk4 tree can handle it very well. 2.4-aa can handle it very
well too.
ciao, Marc
On Wednesday 09 July 2003 12:12, Marc-Christian Petersen wrote:
Hi again,
> Now I am running 2.5.74-mm3, xterm needs about 5 seconds to open up, but
> the whole system is again in a snail mode. XMMS does not skip.
forgot to mention: Running "make -j2 bzImage modules" like you requested :)
ciao, Marc
On Wednesday 09 July 2003 12:22, Con Kolivas wrote:
Hi Con,
> > Now I am running 2.5.74-mm3, xterm needs about 5 seconds to open up, but
> > the whole system is again in a snail mode. XMMS does not skip.
> Well this is no different to the O3 patch on mm2 so it's no surprise :)
sure, but wait up the next mail. I forgot to mention that I do "-j2" now and
not -j8 or -j16 ;)
ciao, Marc
On Wed, 9 Jul 2003 20:12, Marc-Christian Petersen wrote:
> On Tuesday 08 July 2003 02:31, Zwane Mwaikambo wrote:
>
> Hi Zwane,
>
> > > - An Xterm needs ~30 seconds to open up while "make -j16 bzImage
> > > modules" - An Xterm needs ~15 seconds to open up while "make -j8
> > > bzImage modules" - XMMS does _not_ skip mp3's while above.
> >
> > How fast is your box? RAM? disks? I'm personally more interested in 1-2
> > make -j2 bzImage going
>
> - Celeron 1,3GHz
> - 512MB RAM
> - 1GB SWAP (2 IDE disks, ~512MB on each disk)
> - ATA100 Maxtor 60GB HDD
> - ATA100 Fujitsu 40GB
>
> Now I am running 2.5.74-mm3, xterm needs about 5 seconds to open up, but
> the whole system is again in a snail mode. XMMS does not skip.
Well this is no different to the O3 patch on mm2 so it's no surprise :)
Con
>
> > > - Kmail is almost unusable while above (stops for about 5 secs every
> > > 15-20 secs). KMail is also very slow while the machine is doing
> > > nothing. - X runs with nice 0, prio 15 (nice -11 is prio 4, does not
> > > make difference)
> >
> > Looking at above load i'm not entirely surprised, but i presume you're
> > going to name a kernel which can handle that and still complete the
> > builds withing a sane time frame.
>
> For example, my wolk4 tree can handle it very well. 2.4-aa can handle it
> very well too.
>
> ciao, Marc
On Wednesday 09 July 2003 12:37, Con Kolivas wrote:
Hi Con,
> > > > Now I am running 2.5.74-mm3, xterm needs about 5 seconds to open up,
> > > > but the whole system is again in a snail mode. XMMS does not skip.
> > > Well this is no different to the O3 patch on mm2 so it's no surprise :)
> > sure, but wait up the next mail. I forgot to mention that I do "-j2" now
> > and not -j8 or -j16 ;)
> You saying this is somehow slower than before?
No. Where did I say that? :)
recall: I do "-j2" now and not "-j8/-j16" like before in my previous report.
There is no difference with -j8/-j16 comparing .74-mm2 + O3int and .74-mm3
ciao, Marc
On Wed, 9 Jul 2003 20:23, Marc-Christian Petersen wrote:
> On Wednesday 09 July 2003 12:22, Con Kolivas wrote:
>
> Hi Con,
>
> > > Now I am running 2.5.74-mm3, xterm needs about 5 seconds to open up,
> > > but the whole system is again in a snail mode. XMMS does not skip.
> >
> > Well this is no different to the O3 patch on mm2 so it's no surprise :)
>
> sure, but wait up the next mail. I forgot to mention that I do "-j2" now
> and not -j8 or -j16 ;)
>
> ciao, Marc
You saying this is somehow slower than before?
Ciao Marc,
Con
If the prople is all the time complaining about the good that was the
interactivity in the first 2.5 series, is it completly imposible to
revert some of the changes in order to see what has happened?
Perhaps this way, a bug can be identified, or a bad piece of code.
Does this make sense?
Regards,
--
Luis Miguel Garcia
Palencia / Spain
Hi
Sorry for my late answer. I hope it helps even if it's late.
Con Kolivas said:
>
> Ok kick my butt instead so I can try and fix it.
>
>
> Can you tell me how it compares to vanilla at all, and can you watch top
> and see what dynamic priorities are reported for the cc and mplayer
> processes while it's running?
>
Test setup: same config (attached) for kernel. Slackware in runlevel 1
(no daemons).
Kernels tested: 2.5.74 vanila, 2.5.74-mm1, 2.5.74-mm2 with your
patch.
Opening three xterm windows in fvwm2: in one top is feeding
only the running processes in one file, in the
second one "make bzImage" after a make clean with linux-2.4.21
sources and in the third one mplayer /some/movie.avi.
The movie is the same every time.
Results (see atched files):
Vanila kernel is a little bit better than mm. On vanila mplayer has
a smaller priority than cc1 but it still skips frames though is much
smoother. On mm they have the same priority and mplayer skips
worse than on vanila kernel
It seems that gcc uses a lot of cpu while mplayer uses little
cpu so the kernel is favouring the process which eats more cpu .
>> I remeber with nostalgicaly about the times when i could (with a 2.5
>> kernel) do a make -j 5 bzImage AND watch a movie in the same time
>
> <sigh> If it were still the case I wouldn't be spending hundreds of
> hours doing this :|
>
Sorry if I upset you. I apreciate your's (and other's) work on linux
kernel. I'm not a native english speaker and i was just trying to
give an order of magnitude of how the worse kernel is today
(in terms of multimedia) compared with past times.
> Con
Thanks
Bye
Calin
--
# fortune
fortune: write error on /dev/null --- please empty the bit bucket
-----------------------------------------
This email was sent using SquirrelMail.
"Webmail for nuts!"
http://squirrelmail.org/