-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Ingo, all
While messing with the interactivity code I found what appears to be an
uninitialised variable (p->sleep_avg), which is responsible for all the
boost/penalty in the scheduler. Initialising this variable to 0 seems to have
made absolutely massive improvements to system responsiveness under load
and completely removed audio skips up to doing a make -j64 on my uniprocessor
P4 (beyond which swap starts being used), without changing the scheduler
timeslices. This seems to help all 2.4 O(1) based kernels as well. Attached
is a patch against 2.5.72 but I'm not sure about the best place to initialise
it.
diff -Naurp linux-2.5.72/kernel/fork.c linux-2.5.72-test/kernel/fork.c
- --- linux-2.5.72/kernel/fork.c 2003-06-18 22:47:25.000000000 +1000
+++ linux-2.5.72-test/kernel/fork.c 2003-06-19 00:30:26.000000000 +1000
@@ -864,6 +864,7 @@ struct task_struct *copy_process(unsigne
p->lock_depth = -1; /* -1 = no lock */
p->start_time = get_jiffies_64();
p->security = NULL;
+ p->sleep_avg = 0;
retval = -ENOMEM;
if ((retval = security_task_alloc(p)))
diff -Naurp linux-2.5.72/kernel/sched.c linux-2.5.72-test/kernel/sched.c
- --- linux-2.5.72/kernel/sched.c 2003-06-18 22:47:25.000000000 +1000
+++ linux-2.5.72-test/kernel/sched.c 2003-06-19 00:28:19.000000000 +1000
@@ -1755,6 +1755,7 @@ static int setscheduler(pid_t pid, int p
if (array)
deactivate_task(p, task_rq(p));
retval = 0;
+ p->sleep_avg = 0;
p->policy = policy;
p->rt_priority = lp.sched_priority;
if (policy != SCHED_NORMAL)
I hope this is correct.
Regards,
Con
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+8Hp0F6dfvkL3i1gRAr/fAKCYbJ/yQhshqV7G43f+mQP4rZoKWgCfdD69
QuqYH58q6PdbD3qGFvjUKSs=
=huFo
-----END PGP SIGNATURE-----
On Wed, 2003-06-18 at 10:43, Con Kolivas wrote:
> --BEGIN PGP SIGNED MESSAGE--
> Hash: SHA1
>
> Hi Ingo, all
>
> While messing with the interactivity code I found what appears to be an
> uninitialised variable (p->sleep_avg), which is responsible for all the
> boost/penalty in the scheduler. Initialising this variable to 0 seems to have
> made absolutely massive improvements to system responsiveness under load
> and completely removed audio skips up to doing a make -j64 on my uniprocessor
> P4 (beyond which swap starts being used), without changing the scheduler
> timeslices. This seems to help all 2.4 O(1) based kernels as well. Attached
> is a patch against 2.5.72 but I'm not sure about the best place to initialise
> it.
Applying this ontop of 2.5.72-mm1 causes more xmms/mpg321/ogg123
skipping than with plain -mm1 here. make -j20 on my up athlon 1900+ with
512M ram causes extreme skipping until the make is killed. With plain
-mm1 I may get _one_ skip at the very begining of a song during make
-j20 (about 50% of the time). Plain -mm1 stops skipping after 10-15 sec
of playback of a song, and even switching desktops after that doesnt
cause skips, with or without make -j20 running (switching to/from
desktops with apps like mozilla, evolution etc. will cause skips during
the first 10-15 sec of a song regardless what I do it seems).
Renicing xmms to -15 doesnt change anything with either kernel.
Andreas
On Wed, 2003-06-18 at 07:43, Con Kolivas wrote:
> While messing with the interactivity code I found what appears to be an
> uninitialised variable (p->sleep_avg), which is responsible for all the
> boost/penalty in the scheduler.
The variable isn't uninitialized, it is inherited from the parent.
Recall that the task_struct of the new child starts off as a duplicate
of the parent's. If the variables are not explicitly set, they remain
the same as the parent's.
So this patch ends up resetting the sleep_avg to zero, instead of being
the same as the parent, which may or may not result in better
performance.
Robert Love
On Thu, 19 Jun 2003 03:59, Andreas Boman wrote:
> On Wed, 2003-06-18 at 10:43, Con Kolivas wrote:
> > --BEGIN PGP SIGNED MESSAGE--
> > Hash: SHA1
> >
> > Hi Ingo, all
> >
> > While messing with the interactivity code I found what appears to be an
> > uninitialised variable (p->sleep_avg), which is responsible for all the
> > boost/penalty in the scheduler. Initialising this variable to 0 seems to
> > have made absolutely massive improvements to system responsiveness under
> > load and completely removed audio skips up to doing a make -j64 on my
> > uniprocessor P4 (beyond which swap starts being used), without changing
> > the scheduler timeslices. This seems to help all 2.4 O(1) based kernels
> > as well. Attached is a patch against 2.5.72 but I'm not sure about the
> > best place to initialise it.
>
> Applying this ontop of 2.5.72-mm1 causes more xmms/mpg321/ogg123
> skipping than with plain -mm1 here. make -j20 on my up athlon 1900+ with
> 512M ram causes extreme skipping until the make is killed. With plain
> -mm1 I may get _one_ skip at the very begining of a song during make
> -j20 (about 50% of the time). Plain -mm1 stops skipping after 10-15 sec
> of playback of a song, and even switching desktops after that doesnt
> cause skips, with or without make -j20 running (switching to/from
> desktops with apps like mozilla, evolution etc. will cause skips during
> the first 10-15 sec of a song regardless what I do it seems).
>
> Renicing xmms to -15 doesnt change anything with either kernel.
Hmm. I got too excited with the fact it improved so much on the 2.4 O(1)
kernels that I didn't try it hard enough on the 2.5 kernels. I have had
people quietly telling me that it isn't uninitialised, but that I am simply
resetting it with this patch on new forked processes. It seems the extra
changes to the 2.5 scheduler make this patch make things worse?
I need more testing of the 2.4 one as well to see if it was just my
combination of hardware and kernel that was better with this...
Con
On Thu, 19 Jun 2003 08:59, Andreas Boman wrote:
> On Wed, 2003-06-18 at 18:43, Con Kolivas wrote:
> > On Thu, 19 Jun 2003 03:59, Andreas Boman wrote:
> > > On Wed, 2003-06-18 at 10:43, Con Kolivas wrote:
> > > > --BEGIN PGP SIGNED MESSAGE--
> > > > Hash: SHA1
> > > >
> > > > Hi Ingo, all
> > > >
> > > > While messing with the interactivity code I found what appears to be
> > > > an uninitialised variable (p->sleep_avg), which is responsible for
> > > > all the boost/penalty in the scheduler. Initialising this variable to
> > > > 0 seems to have made absolutely massive improvements to system
> > > > responsiveness under load and completely removed audio skips up to
> > > > doing a make -j64 on my uniprocessor P4 (beyond which swap starts
> > > > being used), without changing the scheduler timeslices. This seems to
> > > > help all 2.4 O(1) based kernels as well. Attached is a patch against
> > > > 2.5.72 but I'm not sure about the best place to initialise it.
> > >
> > > Applying this ontop of 2.5.72-mm1 causes more xmms/mpg321/ogg123
> > > skipping than with plain -mm1 here. make -j20 on my up athlon 1900+
> > > with 512M ram causes extreme skipping until the make is killed. With
> > > plain -mm1 I may get _one_ skip at the very begining of a song during
> > > make -j20 (about 50% of the time). Plain -mm1 stops skipping after
> > > 10-15 sec of playback of a song, and even switching desktops after that
> > > doesnt cause skips, with or without make -j20 running (switching
> > > to/from desktops with apps like mozilla, evolution etc. will cause
> > > skips during the first 10-15 sec of a song regardless what I do it
> > > seems).
> > >
> > > Renicing xmms to -15 doesnt change anything with either kernel.
> >
> > Hmm. I got too excited with the fact it improved so much on the 2.4 O(1)
>
> Well, I got very exited when I saw your post ;) I guess this is a
> problem all us UP desktop users would like too see solved.
>
> > kernels that I didn't try it hard enough on the 2.5 kernels. I have had
> > people quietly telling me that it isn't uninitialised, but that I am
> > simply resetting it with this patch on new forked processes. It seems the
> > extra changes to the 2.5 scheduler make this patch make things worse?
>
> Yeah, I poked around a bit after I sent my earlier mail to see what may
> be going on and noticed that too. (In activate_task() and sched_exit()
> and some other place iirc)
>
> > I need more testing of the 2.4 one as well to see if it was just my
> > combination of hardware and kernel that was better with this...
>
> I suspect that is the case, yes, or I got unlucky with mine since it was
> extremely bad during the make -j. I'll see if I can get a 2.4.21-ck
> patched up with some other things I need here, and try to reproduce my
> results. That should tell us if it is infact scheduler differences or
> our different setups.
I had another look at 2.5 and noticed the max sleep avg is set to 10 seconds
instead of 2 seconds in 2.4. This could make a _big_ difference to new forked
tasks if they all start out penalised as most non-interactive. It can take 5
times longer before they get the balance right. Can you try with this set to
2 or even 1 second on 2.5?
Con
On Thu, 19 Jun 2003 10:47, Andreas Boman wrote:
> On Wed, 2003-06-18 at 19:38, Con Kolivas wrote:
> > On Thu, 19 Jun 2003 08:59, Andreas Boman wrote:
> > > On Wed, 2003-06-18 at 18:43, Con Kolivas wrote:
> > > > On Thu, 19 Jun 2003 03:59, Andreas Boman wrote:
> > > > > On Wed, 2003-06-18 at 10:43, Con Kolivas wrote:
> > > > > > --BEGIN PGP SIGNED MESSAGE--
> > > > > > Hash: SHA1
> > > > > >
> > > > > > Hi Ingo, all
> > > > > >
> > > > > > While messing with the interactivity code I found what appears to
> > > > > > be an uninitialised variable (p->sleep_avg), which is responsible
> > > > > > for all the boost/penalty in the scheduler. Initialising this
> > > > > > variable to 0 seems to have made absolutely massive improvements
> > > > > > to system responsiveness under load and completely removed audio
> > > > > > skips up to doing a make -j64 on my uniprocessor P4 (beyond which
> > > > > > swap starts being used), without changing the scheduler
> > > > > > timeslices. This seems to help all 2.4 O(1) based kernels as
> > > > > > well. Attached is a patch against 2.5.72 but I'm not sure about
> > > > > > the best place to initialise it.
> > > > >
> > > > > Applying this ontop of 2.5.72-mm1 causes more xmms/mpg321/ogg123
> > > > > skipping than with plain -mm1 here. make -j20 on my up athlon 1900+
> > > > > with 512M ram causes extreme skipping until the make is killed.
> > > > > With plain -mm1 I may get _one_ skip at the very begining of a song
> > > > > during make -j20 (about 50% of the time). Plain -mm1 stops skipping
> > > > > after 10-15 sec of playback of a song, and even switching desktops
> > > > > after that doesnt cause skips, with or without make -j20 running
> > > > > (switching to/from desktops with apps like mozilla, evolution etc.
> > > > > will cause skips during the first 10-15 sec of a song regardless
> > > > > what I do it seems).
> > > > >
> > > > > Renicing xmms to -15 doesnt change anything with either kernel.
> > > >
> > > > Hmm. I got too excited with the fact it improved so much on the 2.4
> > > > O(1)
> > >
> > > Well, I got very exited when I saw your post ;) I guess this is a
> > > problem all us UP desktop users would like too see solved.
> > >
> > > > kernels that I didn't try it hard enough on the 2.5 kernels. I have
> > > > had people quietly telling me that it isn't uninitialised, but that I
> > > > am simply resetting it with this patch on new forked processes. It
> > > > seems the extra changes to the 2.5 scheduler make this patch make
> > > > things worse?
> > >
> > > Yeah, I poked around a bit after I sent my earlier mail to see what may
> > > be going on and noticed that too. (In activate_task() and sched_exit()
> > > and some other place iirc)
> > >
> > > > I need more testing of the 2.4 one as well to see if it was just my
> > > > combination of hardware and kernel that was better with this...
> > >
> > > I suspect that is the case, yes, or I got unlucky with mine since it
> > > was extremely bad during the make -j. I'll see if I can get a 2.4.21-ck
> > > patched up with some other things I need here, and try to reproduce my
> > > results. That should tell us if it is infact scheduler differences or
> > > our different setups.
> >
> > I had another look at 2.5 and noticed the max sleep avg is set to 10
> > seconds instead of 2 seconds in 2.4. This could make a _big_ difference
> > to new forked tasks if they all start out penalised as most
> > non-interactive. It can take 5 times longer before they get the balance
> > right. Can you try with this set to 2 or even 1 second on 2.5?
>
> Ahh, thanks Con, setting MAX_SLEEP_AVG to 2 *almost* removes all xmms
> skipping here, a song *may* skip during desktop switches sometime during
> the first 5 sec or so of playback IFF make -j20 is running. On a mostly
> idle box (well LoadAvg 3 or so is mostly idle isnt it? ;) desktop
> switching doesnt cause skips anymore 8)
That's nice; a MAX_SLEEP_AVG of 1 second will shorten that 5 seconds to half
that as well. What you describe makes perfect sense given that achieving a
balance is an exponential function where the MSA is the time constant.
> Doing make -j20 and staying on the same desktop doesnt cause any
> skipping at all (but it didnt cause much skipping at all on plain
> 2.5.72-mm1 either).
So it is better than the default mm1? (doesnt cause any vs didnt cause much)
> I also applied your p->sleep_avg = 0; stuff (keeping MAX_SLEEP_AVG 2 and
> HZ 1000) and it behaved just like I described earlier (songs started
> after the make never stop skipping).
Well anything started will be penalised initially as being completely
non-interactive with the p->sleep_avg = 0. This seems to work fine for normal
usage patterns I've found on -ck1, as after a short while it gets a bonus up
to interactive. But you say that doesn't happen on 2.5?
> I am fairly sure the winner for me here was the MAX_SLEEP_AVG since I
> have fiddled with HZ before without it making big noticable differences.
Yes you're confirming pretty much what I'm finding now that I've played with
it a lot more.
> I havent gotten a 2.4 kernel patched up yet (lazy), but I'll get that
> done and see how that sleep_avg patch behaves here then.
Shouldn't be any different than what you've described on 2.5 now, if you make
CHILD_PENALTY match that on 2.5 (is 50 in 2.5, was 95 in -ck1)
Con
P.S. I've cc'ed lkml since others might find this information interesting
On Wed, 2003-06-18 at 21:12, Con Kolivas wrote:
> On Thu, 19 Jun 2003 10:47, Andreas Boman wrote:
> > On Wed, 2003-06-18 at 19:38, Con Kolivas wrote:
> > > On Thu, 19 Jun 2003 08:59, Andreas Boman wrote:
> > > > On Wed, 2003-06-18 at 18:43, Con Kolivas wrote:
> > > > > On Thu, 19 Jun 2003 03:59, Andreas Boman wrote:
> > > > > > On Wed, 2003-06-18 at 10:43, Con Kolivas wrote:
> > > > > > > --BEGIN PGP SIGNED MESSAGE--
> > > > > > > Hash: SHA1
> > > > > > >
> > > > > > > Hi Ingo, all
> > > > > > >
> > > > > > > While messing with the interactivity code I found what appears to
> > > > > > > be an uninitialised variable (p->sleep_avg), which is responsible
> > > > > > > for all the boost/penalty in the scheduler. Initialising this
> > > > > > > variable to 0 seems to have made absolutely massive improvements
> > > > > > > to system responsiveness under load and completely removed audio
> > > > > > > skips up to doing a make -j64 on my uniprocessor P4 (beyond which
> > > > > > > swap starts being used), without changing the scheduler
> > > > > > > timeslices. This seems to help all 2.4 O(1) based kernels as
> > > > > > > well. Attached is a patch against 2.5.72 but I'm not sure about
> > > > > > > the best place to initialise it.
> > > > > >
> > > > > > Applying this ontop of 2.5.72-mm1 causes more xmms/mpg321/ogg123
> > > > > > skipping than with plain -mm1 here. make -j20 on my up athlon 1900+
> > > > > > with 512M ram causes extreme skipping until the make is killed.
> > > > > > With plain -mm1 I may get _one_ skip at the very begining of a song
> > > > > > during make -j20 (about 50% of the time). Plain -mm1 stops skipping
> > > > > > after 10-15 sec of playback of a song, and even switching desktops
> > > > > > after that doesnt cause skips, with or without make -j20 running
> > > > > > (switching to/from desktops with apps like mozilla, evolution etc.
> > > > > > will cause skips during the first 10-15 sec of a song regardless
> > > > > > what I do it seems).
> > > > > >
> > > > > > Renicing xmms to -15 doesnt change anything with either kernel.
> > > > >
> > > > > Hmm. I got too excited with the fact it improved so much on the 2.4
> > > > > O(1)
> > > >
> > > > Well, I got very exited when I saw your post ;) I guess this is a
> > > > problem all us UP desktop users would like too see solved.
> > > >
> > > > > kernels that I didn't try it hard enough on the 2.5 kernels. I have
> > > > > had people quietly telling me that it isn't uninitialised, but that I
> > > > > am simply resetting it with this patch on new forked processes. It
> > > > > seems the extra changes to the 2.5 scheduler make this patch make
> > > > > things worse?
> > > >
> > > > Yeah, I poked around a bit after I sent my earlier mail to see what may
> > > > be going on and noticed that too. (In activate_task() and sched_exit()
> > > > and some other place iirc)
> > > >
> > > > > I need more testing of the 2.4 one as well to see if it was just my
> > > > > combination of hardware and kernel that was better with this...
> > > >
> > > > I suspect that is the case, yes, or I got unlucky with mine since it
> > > > was extremely bad during the make -j. I'll see if I can get a 2.4.21-ck
> > > > patched up with some other things I need here, and try to reproduce my
> > > > results. That should tell us if it is infact scheduler differences or
> > > > our different setups.
> > >
> > > I had another look at 2.5 and noticed the max sleep avg is set to 10
> > > seconds instead of 2 seconds in 2.4. This could make a _big_ difference
> > > to new forked tasks if they all start out penalised as most
> > > non-interactive. It can take 5 times longer before they get the balance
> > > right. Can you try with this set to 2 or even 1 second on 2.5?
> >
> > Ahh, thanks Con, setting MAX_SLEEP_AVG to 2 *almost* removes all xmms
> > skipping here, a song *may* skip during desktop switches sometime during
> > the first 5 sec or so of playback IFF make -j20 is running. On a mostly
> > idle box (well LoadAvg 3 or so is mostly idle isnt it? ;) desktop
> > switching doesnt cause skips anymore 8)
>
> That's nice; a MAX_SLEEP_AVG of 1 second will shorten that 5 seconds to half
> that as well. What you describe makes perfect sense given that achieving a
> balance is an exponential function where the MSA is the time constant.
Right.
> > Doing make -j20 and staying on the same desktop doesnt cause any
> > skipping at all (but it didnt cause much skipping at all on plain
> > 2.5.72-mm1 either).
>
> So it is better than the default mm1? (doesnt cause any vs didnt cause much)
Yes.
> > I also applied your p->sleep_avg = 0; stuff (keeping MAX_SLEEP_AVG 2 and
> > HZ 1000) and it behaved just like I described earlier (songs started
> > after the make never stop skipping).
>
> Well anything started will be penalised initially as being completely
> non-interactive with the p->sleep_avg = 0. This seems to work fine for normal
> usage patterns I've found on -ck1, as after a short while it gets a bonus up
> to interactive. But you say that doesn't happen on 2.5?
It doesnt seem like it, xmms gets completely starved. A song started
before the make -j plays through fine while songs started after the make
-j just skip perpetually until I kill the player or the make.
> > I am fairly sure the winner for me here was the MAX_SLEEP_AVG since I
> > have fiddled with HZ before without it making big noticable differences.
>
> Yes you're confirming pretty much what I'm finding now that I've played with
> it a lot more.
>
> > I havent gotten a 2.4 kernel patched up yet (lazy), but I'll get that
> > done and see how that sleep_avg patch behaves here then.
>
> Shouldn't be any different than what you've described on 2.5 now, if you make
> CHILD_PENALTY match that on 2.5 (is 50 in 2.5, was 95 in -ck1)
Right, I'll take a look at all thoose magic numbers so I'll have the
same settings.
Andreas
At 11:12 AM 6/19/2003 +1000, Con Kolivas wrote:
>On Thu, 19 Jun 2003 10:47, Andreas Boman wrote:
> > On Wed, 2003-06-18 at 19:38, Con Kolivas wrote:
> > >
> > > I had another look at 2.5 and noticed the max sleep avg is set to 10
> > > seconds instead of 2 seconds in 2.4. This could make a _big_ difference
> > > to new forked tasks if they all start out penalised as most
> > > non-interactive. It can take 5 times longer before they get the balance
> > > right. Can you try with this set to 2 or even 1 second on 2.5?
> >
> > Ahh, thanks Con, setting MAX_SLEEP_AVG to 2 *almost* removes all xmms
> > skipping here, a song *may* skip during desktop switches sometime during
> > the first 5 sec or so of playback IFF make -j20 is running. On a mostly
> > idle box (well LoadAvg 3 or so is mostly idle isnt it? ;) desktop
> > switching doesnt cause skips anymore 8)
>
>That's nice; a MAX_SLEEP_AVG of 1 second will shorten that 5 seconds to half
>that as well. What you describe makes perfect sense given that achieving a
>balance is an exponential function where the MSA is the time constant.
However, that will also send X and friends go off to the expired array
_very_ quickly. This will certainly destroy interactive feel under load
because your desktop can/will go away for seconds at a time. Try to drag a
window while a make -j10 is running, and it'll get choppy as heck. AFAIKT,
anything that you do to increase concurrency in a global manner is _going_
to have the side effect of damaging interactive feel to some extent. The
one and only source of desktop responsiveness is the large repository of
cpu ticks a task is allowed to save up for a rainy day.
What I would love to figure out is a way to reintroduce back-boost without
it having global impact. I think hogging the cpu is absolutely _wonderful_
when the hogs are the tasks I'm interacting with. Unfortunately, there
seems to be no way to determine whether a human is intimately involved or
not other than to specifically tell the scheduler this via renice.
> > Doing make -j20 and staying on the same desktop doesnt cause any
> > skipping at all (but it didnt cause much skipping at all on plain
> > 2.5.72-mm1 either).
>
>So it is better than the default mm1? (doesnt cause any vs didnt cause much)
>
> > I also applied your p->sleep_avg = 0; stuff (keeping MAX_SLEEP_AVG 2 and
> > HZ 1000) and it behaved just like I described earlier (songs started
> > after the make never stop skipping).
>
>Well anything started will be penalised initially as being completely
>non-interactive with the p->sleep_avg = 0. This seems to work fine for normal
>usage patterns I've found on -ck1, as after a short while it gets a bonus up
>to interactive. But you say that doesn't happen on 2.5?
>
> > I am fairly sure the winner for me here was the MAX_SLEEP_AVG since I
> > have fiddled with HZ before without it making big noticable differences.
>
>Yes you're confirming pretty much what I'm finding now that I've played with
>it a lot more.
>
> > I havent gotten a 2.4 kernel patched up yet (lazy), but I'll get that
> > done and see how that sleep_avg patch behaves here then.
>
>Shouldn't be any different than what you've described on 2.5 now, if you make
>CHILD_PENALTY match that on 2.5 (is 50 in 2.5, was 95 in -ck1)
This is the easy way to cure xmms's problem of new thread starting at too
low priority, but it also shows the other side of the coin. With this
change, your interactive feel will be wonderful. However, when you start a
cpu hog, it starts it's life with a fully loaded starve-me battery. What
happens when a highly charged task forks off a bunch of cpu hogs? Yup,
mega-starvation until they burn off the pre-charge.
Sigh, scheduling is a _bitch_.
-Mike
On Thu, 19 Jun 2003 16:13, Mike Galbraith wrote:
> At 11:12 AM 6/19/2003 +1000, Con Kolivas wrote:
> >On Thu, 19 Jun 2003 10:47, Andreas Boman wrote:
> > > On Wed, 2003-06-18 at 19:38, Con Kolivas wrote:
> > > > I had another look at 2.5 and noticed the max sleep avg is set to 10
> > > > seconds instead of 2 seconds in 2.4. This could make a _big_
> > > > difference to new forked tasks if they all start out penalised as
> > > > most
> > > > non-interactive. It can take 5 times longer before they get the
> > > > balance right. Can you try with this set to 2 or even 1 second on
> > > > 2.5?
> > >
> > > Ahh, thanks Con, setting MAX_SLEEP_AVG to 2 *almost* removes all xmms
> > > skipping here, a song *may* skip during desktop switches sometime
> > > during the first 5 sec or so of playback IFF make -j20 is running. On a
> > > mostly idle box (well LoadAvg 3 or so is mostly idle isnt it? ;)
> > > desktop switching doesnt cause skips anymore 8)
> >
> >That's nice; a MAX_SLEEP_AVG of 1 second will shorten that 5 seconds to
> > half that as well. What you describe makes perfect sense given that
> > achieving a balance is an exponential function where the MSA is the time
> > constant.
>
> However, that will also send X and friends go off to the expired array
> _very_ quickly. This will certainly destroy interactive feel under load
> because your desktop can/will go away for seconds at a time. Try to drag a
> window while a make -j10 is running, and it'll get choppy as heck. AFAIKT,
> anything that you do to increase concurrency in a global manner is _going_
> to have the side effect of damaging interactive feel to some extent. The
> one and only source of desktop responsiveness is the large repository of
> cpu ticks a task is allowed to save up for a rainy day.
Indeed that's what I thought and found as well. I have a question though - do
non interactive tasks have periods of inactivity where they collect sleep
times or is it just interactive tasks that exhibit this? Why I'm asking is,
what if the interactivity bonus is based on the best interactive setting that
task has received, and make this one much slower at decaying than the
sleep_avg. Say one second for max_sleep_avg and 60 seconds for
max_interactive_bonus? So it can become interactive very quickly (and
therefore also should start as non interactive) but becomes non-interactive
slowly.
> Sigh, scheduling is a _bitch_.
Indeed
Con.
Mike Galbraith wrote:
> At 11:12 AM 6/19/2003 +1000, Con Kolivas wrote:
>
>> On Thu, 19 Jun 2003 10:47, Andreas Boman wrote:
>> > On Wed, 2003-06-18 at 19:38, Con Kolivas wrote:
>> > >
>> > > I had another look at 2.5 and noticed the max sleep avg is set to 10
>> > > seconds instead of 2 seconds in 2.4. This could make a _big_
>> difference
>> > > to new forked tasks if they all start out penalised as most
>> > > non-interactive. It can take 5 times longer before they get the
>> balance
>> > > right. Can you try with this set to 2 or even 1 second on 2.5?
>> >
>> > Ahh, thanks Con, setting MAX_SLEEP_AVG to 2 *almost* removes all xmms
>> > skipping here, a song *may* skip during desktop switches sometime
>> during
>> > the first 5 sec or so of playback IFF make -j20 is running. On a
>> mostly
>> > idle box (well LoadAvg 3 or so is mostly idle isnt it? ;) desktop
>> > switching doesnt cause skips anymore 8)
>>
>> That's nice; a MAX_SLEEP_AVG of 1 second will shorten that 5 seconds
>> to half
>> that as well. What you describe makes perfect sense given that
>> achieving a
>> balance is an exponential function where the MSA is the time constant.
>
>
> However, that will also send X and friends go off to the expired array
> _very_ quickly. This will certainly destroy interactive feel under
> load because your desktop can/will go away for seconds at a time. Try
> to drag a window while a make -j10 is running, and it'll get choppy as
> heck. AFAIKT, anything that you do to increase concurrency in a
> global manner is _going_ to have the side effect of damaging
> interactive feel to some extent. The one and only source of desktop
> responsiveness is the large repository of cpu ticks a task is allowed
> to save up for a rainy day.
>
> What I would love to figure out is a way to reintroduce back-boost
> without it having global impact. I think hogging the cpu is
> absolutely _wonderful_ when the hogs are the tasks I'm interacting
> with. Unfortunately, there seems to be no way to determine whether a
> human is intimately involved or not other than to specifically tell
> the scheduler this via renice.
Could certian drivers or subsystems say they are interactive and
provide some input to the scheduler that way? Reads from input
devices for example could increase a processes "interactivity" a
lot, while writes to console or ... no, everything gets multiplexed
through X, doesn't it...
The backboost was quite a good idea. I didn't follow it closely
but what if you impemented the above idea, which increased
an "interactiveness" number, then X clients could simply have
their interactiveness value boosted by X?
Am I rambling? ;)
On Thu, 19 Jun 2003 16:35, Con Kolivas wrote:
> On Thu, 19 Jun 2003 16:13, Mike Galbraith wrote:
> > At 11:12 AM 6/19/2003 +1000, Con Kolivas wrote:
> > >On Thu, 19 Jun 2003 10:47, Andreas Boman wrote:
> > > > On Wed, 2003-06-18 at 19:38, Con Kolivas wrote:
> > > > > I had another look at 2.5 and noticed the max sleep avg is set to
> > > > > 10 seconds instead of 2 seconds in 2.4. This could make a _big_
> > > > > difference to new forked tasks if they all start out penalised as
> > > > > most
> > > > > non-interactive. It can take 5 times longer before they get the
> > > > > balance right. Can you try with this set to 2 or even 1 second on
> > > > > 2.5?
> > > >
> > > > Ahh, thanks Con, setting MAX_SLEEP_AVG to 2 *almost* removes all xmms
> > > > skipping here, a song *may* skip during desktop switches sometime
> > > > during the first 5 sec or so of playback IFF make -j20 is running. On
> > > > a mostly idle box (well LoadAvg 3 or so is mostly idle isnt it? ;)
> > > > desktop switching doesnt cause skips anymore 8)
> > >
> > >That's nice; a MAX_SLEEP_AVG of 1 second will shorten that 5 seconds to
> > > half that as well. What you describe makes perfect sense given that
> > > achieving a balance is an exponential function where the MSA is the
> > > time constant.
> >
> > However, that will also send X and friends go off to the expired array
> > _very_ quickly. This will certainly destroy interactive feel under load
> > because your desktop can/will go away for seconds at a time. Try to drag
> > a window while a make -j10 is running, and it'll get choppy as heck.
> > AFAIKT, anything that you do to increase concurrency in a global manner
> > is _going_ to have the side effect of damaging interactive feel to some
> > extent. The one and only source of desktop responsiveness is the large
> > repository of cpu ticks a task is allowed to save up for a rainy day.
>
> Indeed that's what I thought and found as well. I have a question though -
> do non interactive tasks have periods of inactivity where they collect
> sleep times or is it just interactive tasks that exhibit this? Why I'm
> asking is, what if the interactivity bonus is based on the best interactive
> setting that task has received, and make this one much slower at decaying
> than the sleep_avg. Say one second for max_sleep_avg and 60 seconds for
> max_interactive_bonus? So it can become interactive very quickly (and
> therefore also should start as non interactive) but becomes non-interactive
> slowly.
I tried creating this myself and on first testing it seems the best all round
so far. I'll make a patch later on for ppl to try, but in a nutshell it does
this in sched.h:
unsigned long sleep_avg;
+ unsigned long best_sleep_avg;
unsigned long sleep_timestamp;
this in sched.c:
#define MAX_SLEEP_AVG (HZ)
...
bonus =
MAX_USER_PRIO*PRIO_BONUS_RATIO*(p->best_sleep_avg/100)/MAX_SLEEP_AVG/100 -
MAX_USER_PRIO*PRIO_BONUS_RATIO/100/2;
...
p->sleep_avg = MAX_SLEEP_AVG;
+ if ((p->sleep_avg * 100) > p->best_sleep_avg)
+ p->best_sleep_avg = p->sleep_avg * 100;
p->prio = effective_prio(p);
...
p->sleep_avg--;
+ if (p->best_sleep_avg)
+ p->best_sleep_avg--;
...
p->rt_priority = lp.sched_priority;
+ p->sleep_avg = 0;
+ p->best_sleep_avg = 0;
and this in fork.c:
p->sleep_timestamp = jiffies;
+ p->sleep_avg = 0;
+ p->best_sleep_avg = 0;
Sorry I dont have a full patch for people to try at this moment as there are
so many O(1) kernels I"m working with. This basically works out the sleep
average over 1 second, but the priority on the best over 100 seconds.
Con
At 05:33 PM 6/19/2003 +1000, Nick Piggin wrote:
>Mike Galbraith wrote:
>
>>At 11:12 AM 6/19/2003 +1000, Con Kolivas wrote:
>>
>>>On Thu, 19 Jun 2003 10:47, Andreas Boman wrote:
>>> > On Wed, 2003-06-18 at 19:38, Con Kolivas wrote:
>>> > >
>>> > > I had another look at 2.5 and noticed the max sleep avg is set to 10
>>> > > seconds instead of 2 seconds in 2.4. This could make a _big_ difference
>>> > > to new forked tasks if they all start out penalised as most
>>> > > non-interactive. It can take 5 times longer before they get the balance
>>> > > right. Can you try with this set to 2 or even 1 second on 2.5?
>>> >
>>> > Ahh, thanks Con, setting MAX_SLEEP_AVG to 2 *almost* removes all xmms
>>> > skipping here, a song *may* skip during desktop switches sometime during
>>> > the first 5 sec or so of playback IFF make -j20 is running. On a mostly
>>> > idle box (well LoadAvg 3 or so is mostly idle isnt it? ;) desktop
>>> > switching doesnt cause skips anymore 8)
>>>
>>>That's nice; a MAX_SLEEP_AVG of 1 second will shorten that 5 seconds to half
>>>that as well. What you describe makes perfect sense given that achieving a
>>>balance is an exponential function where the MSA is the time constant.
>>
>>
>>However, that will also send X and friends go off to the expired array
>>_very_ quickly. This will certainly destroy interactive feel under load
>>because your desktop can/will go away for seconds at a time. Try to drag
>>a window while a make -j10 is running, and it'll get choppy as
>>heck. AFAIKT, anything that you do to increase concurrency in a global
>>manner is _going_ to have the side effect of damaging interactive feel to
>>some extent. The one and only source of desktop responsiveness is the
>>large repository of cpu ticks a task is allowed to save up for a rainy day.
>>
>>What I would love to figure out is a way to reintroduce back-boost
>>without it having global impact. I think hogging the cpu is absolutely
>>_wonderful_ when the hogs are the tasks I'm interacting
>>with. Unfortunately, there seems to be no way to determine whether a
>>human is intimately involved or not other than to specifically tell the
>>scheduler this via renice.
>
>
>Could certian drivers or subsystems say they are interactive and
>provide some input to the scheduler that way? Reads from input
>devices for example could increase a processes "interactivity" a
>lot, while writes to console or ... no, everything gets multiplexed
>through X, doesn't it...
The mouse and keyboard are wonderful candidates for this... there's always
a human connected. It's too bad there's no way to tell if a human is
staring at the display. If I'm mesmerized by xmms gl eye-candy, it's a
highly interactive cpu hog.
>The backboost was quite a good idea. I didn't follow it closely
>but what if you impemented the above idea, which increased
>an "interactiveness" number, then X clients could simply have
>their interactiveness value boosted by X?
Sounds good. What I'm trying within the current framework is to let tasks
which are extremely light weight (and not kernel threads) do
backboost. Dunno if anything good will come out of it.
>Am I rambling? ;)
IMHO, the more people who ruminate/ramble on this very hard subject the better.
-Mike
Mike Galbraith wrote:
> At 05:33 PM 6/19/2003 +1000, Nick Piggin wrote:
>
>> Mike Galbraith wrote:
>>
>>>
>>> However, that will also send X and friends go off to the expired
>>> array _very_ quickly. This will certainly destroy interactive feel
>>> under load because your desktop can/will go away for seconds at a
>>> time. Try to drag a window while a make -j10 is running, and it'll
>>> get choppy as heck. AFAIKT, anything that you do to increase
>>> concurrency in a global manner is _going_ to have the side effect of
>>> damaging interactive feel to some extent. The one and only source
>>> of desktop responsiveness is the large repository of cpu ticks a
>>> task is allowed to save up for a rainy day.
>>>
>>> What I would love to figure out is a way to reintroduce back-boost
>>> without it having global impact. I think hogging the cpu is
>>> absolutely _wonderful_ when the hogs are the tasks I'm interacting
>>> with. Unfortunately, there seems to be no way to determine whether
>>> a human is intimately involved or not other than to specifically
>>> tell the scheduler this via renice.
>>
>>
>>
>> Could certian drivers or subsystems say they are interactive and
>> provide some input to the scheduler that way? Reads from input
>> devices for example could increase a processes "interactivity" a
>> lot, while writes to console or ... no, everything gets multiplexed
>> through X, doesn't it...
>
>
> The mouse and keyboard are wonderful candidates for this... there's
> always a human connected. It's too bad there's no way to tell if a
> human is staring at the display. If I'm mesmerized by xmms gl
> eye-candy, it's a highly interactive cpu hog.
Thats right, but console / DRI / whatever could probably provide a small
interactivity boost.
>
>> The backboost was quite a good idea. I didn't follow it closely
>> but what if you impemented the above idea, which increased
>> an "interactiveness" number, then X clients could simply have
>> their interactiveness value boosted by X?
>
>
> Sounds good. What I'm trying within the current framework is to let
> tasks which are extremely light weight (and not kernel threads) do
> backboost. Dunno if anything good will come out of it.
OK, the backboost is what? A dynamic priority boost? This is so
X for example can be made interactive through its clients even
if its hogging a lot of CPU, right?
I think it might be a good idea to introduce an "interactiveness"
measurement which could be boosted by interactive devices, and a
forwardboost would be able to increase an X client's interactivenss
through X.
in
Nick Piggin wrote:
>
>
> Mike Galbraith wrote:
>
>> At 05:33 PM 6/19/2003 +1000, Nick Piggin wrote:
>>
>>> Mike Galbraith wrote:
>>>
>>>>
>>>> However, that will also send X and friends go off to the expired
>>>> array _very_ quickly. This will certainly destroy interactive feel
>>>> under load because your desktop can/will go away for seconds at a
>>>> time. Try to drag a window while a make -j10 is running, and it'll
>>>> get choppy as heck. AFAIKT, anything that you do to increase
>>>> concurrency in a global manner is _going_ to have the side effect
>>>> of damaging interactive feel to some extent. The one and only
>>>> source of desktop responsiveness is the large repository of cpu
>>>> ticks a task is allowed to save up for a rainy day.
>>>>
>>>> What I would love to figure out is a way to reintroduce back-boost
>>>> without it having global impact. I think hogging the cpu is
>>>> absolutely _wonderful_ when the hogs are the tasks I'm interacting
>>>> with. Unfortunately, there seems to be no way to determine whether
>>>> a human is intimately involved or not other than to specifically
>>>> tell the scheduler this via renice.
>>>
>>>
>>>
>>>
>>> Could certian drivers or subsystems say they are interactive and
>>> provide some input to the scheduler that way? Reads from input
>>> devices for example could increase a processes "interactivity" a
>>> lot, while writes to console or ... no, everything gets multiplexed
>>> through X, doesn't it...
>>
>>
>>
>> The mouse and keyboard are wonderful candidates for this... there's
>> always a human connected. It's too bad there's no way to tell if a
>> human is staring at the display. If I'm mesmerized by xmms gl
>> eye-candy, it's a highly interactive cpu hog.
>
>
>
> Thats right, but console / DRI / whatever could probably provide a small
> interactivity boost.
Soundcard even...
At 06:57 PM 6/19/2003 +1000, Nick Piggin wrote:
>Mike Galbraith wrote:
>
>>At 05:33 PM 6/19/2003 +1000, Nick Piggin wrote:
>>
>>>Mike Galbraith wrote:
>>>
>>>>
>>>>However, that will also send X and friends go off to the expired array
>>>>_very_ quickly. This will certainly destroy interactive feel under
>>>>load because your desktop can/will go away for seconds at a time. Try
>>>>to drag a window while a make -j10 is running, and it'll get choppy as
>>>>heck. AFAIKT, anything that you do to increase concurrency in a global
>>>>manner is _going_ to have the side effect of damaging interactive feel
>>>>to some extent. The one and only source of desktop responsiveness is
>>>>the large repository of cpu ticks a task is allowed to save up for a rainy day.
>>>>
>>>>What I would love to figure out is a way to reintroduce back-boost
>>>>without it having global impact. I think hogging the cpu is absolutely
>>>>_wonderful_ when the hogs are the tasks I'm interacting
>>>>with. Unfortunately, there seems to be no way to determine whether a
>>>>human is intimately involved or not other than to specifically tell the
>>>>scheduler this via renice.
>>>
>>>
>>>
>>>Could certian drivers or subsystems say they are interactive and
>>>provide some input to the scheduler that way? Reads from input
>>>devices for example could increase a processes "interactivity" a
>>>lot, while writes to console or ... no, everything gets multiplexed
>>>through X, doesn't it...
>>
>>
>>The mouse and keyboard are wonderful candidates for this... there's
>>always a human connected. It's too bad there's no way to tell if a human
>>is staring at the display. If I'm mesmerized by xmms gl eye-candy, it's
>>a highly interactive cpu hog.
>
>
>Thats right, but console / DRI / whatever could probably provide a small
>interactivity boost.
Yes. I was thinking about the wastage when I get bored and minimize or
cover up eye-candy. For that kind of stuff, the existing scheduler
syscalls would probably be much more efficient, because userland knows if I
can see cpu oinker's output.
>>>The backboost was quite a good idea. I didn't follow it closely
>>>but what if you impemented the above idea, which increased
>>>an "interactiveness" number, then X clients could simply have
>>>their interactiveness value boosted by X?
>>
>>
>>Sounds good. What I'm trying within the current framework is to let
>>tasks which are extremely light weight (and not kernel threads) do
>>backboost. Dunno if anything good will come out of it.
>
>
>OK, the backboost is what? A dynamic priority boost? This is so
>X for example can be made interactive through its clients even
>if its hogging a lot of CPU, right?
Exactly. That's what made backboost so wonderful... X/KDE wiggies boosted
each other.
>I think it might be a good idea to introduce an "interactiveness"
>measurement which could be boosted by interactive devices, and a
>forwardboost would be able to increase an X client's interactivenss
>through X.
Yes.
>in
(messagus interruptus?)
-Mike