2.5.72 O(1) interactivity bugfix

PATCH In review Con Kolivas 5 participants 15 messages Jun 18, 2003 – Jun 19, 2003 2 messages not in the archive

lore

Share & tools

lore

Con Kolivas

author

2003-06-18 14:29 UTC #0 lore raw

PATCH 1/1 2.5.72 O(1) interactivity bugfix

-----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-----

Andreas Boman

2003-06-18 17:45 UTC #1 lore raw

Quoted 5 lines · Con Kolivas

--BEGIN PGP SIGNED MESSAGE--
Hash: SHA1
Hi Ingo, all

Quoted 9 lines

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

Con Kolivas

author

2003-06-18 22:29 UTC #2 lore raw

Quoted 26 lines · Andreas Boman

Quoted 5 lines · Con Kolivas
--BEGIN PGP SIGNED MESSAGE--
Hash: SHA1
Hi Ingo, all
Quoted 9 lines
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
(quoted diff) +0 -2
-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).

Quoted 1 line

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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Con Kolivas

author

2003-06-18 23:24 UTC #4 lore raw

Quoted 45 lines · Andreas Boman

Quoted 28 lines · Con Kolivas
Quoted 27 lines · Andreas Boman
Quoted 5 lines · Con Kolivas
--BEGIN PGP SIGNED MESSAGE--
Hash: SHA1
Hi Ingo, all
Quoted 9 lines
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).
Quoted 3 lines
Quoted 1 line
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.
Quoted 4 lines
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)

Quoted 8 lines

Quoted 2 lines
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

A message that is not in the archive (sent off-list or not yet received): [email protected]

Con Kolivas

author

2003-06-19 00:58 UTC #6 lore raw

Quoted 65 lines · Andreas Boman

Quoted 58 lines · Con Kolivas
Quoted 48 lines · Andreas Boman
Quoted 29 lines · Con Kolivas
Quoted 28 lines · Andreas Boman
Quoted 5 lines · Con Kolivas
--BEGIN PGP SIGNED MESSAGE--
Hash: SHA1
Hi Ingo, all
Quoted 10 lines
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).
Quoted 4 lines
Quoted 1 line
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.
Quoted 5 lines
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)
Quoted 8 lines
Quoted 2 lines
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.
Quoted 5 lines
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?

Quoted 5 lines

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.

Quoted 3 lines

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)

Quoted 3 lines

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?

Quoted 2 lines

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.

Quoted 2 lines

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

Andreas Boman

2003-06-19 01:46 UTC #7 lore raw

Quoted 72 lines · Con Kolivas

Quoted 65 lines · Andreas Boman
Quoted 58 lines · Con Kolivas
Quoted 48 lines · Andreas Boman
Quoted 29 lines · Con Kolivas
Quoted 28 lines · Andreas Boman
Quoted 5 lines · Con Kolivas
--BEGIN PGP SIGNED MESSAGE--
Hash: SHA1
Hi Ingo, all
Quoted 10 lines
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).
Quoted 4 lines
Quoted 1 line
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.
Quoted 5 lines
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)
Quoted 8 lines
Quoted 2 lines
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.
Quoted 5 lines
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?
Quoted 5 lines
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)

Quoted 3 lines

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.

Quoted 5 lines

Quoted 3 lines
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.

Quoted 8 lines

Quoted 3 lines
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.

Quoted 11 lines

Quoted 2 lines
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.
Quoted 2 lines
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

Mike Galbraith

2003-06-19 05:54 UTC #8 lore raw

In reply to Con Kolivas

Quoted 15 lines · Con Kolivas

Quoted 8 lines · Andreas Boman
Quoted 6 lines · Con Kolivas
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?
Quoted 5 lines
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)

Quoted 3 lines

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.

Quoted 18 lines

Quoted 3 lines
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)
Quoted 3 lines
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?
Quoted 2 lines
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.

Quoted 8 lines

Yes you're confirming pretty much what I'm finding now that I've played with it a lot more.
Quoted 2 lines
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

Con Kolivas

author

2003-06-19 06:21 UTC #9 lore raw

Quoted 22 lines · Mike Galbraith

Quoted 16 lines · Con Kolivas
Quoted 9 lines · Andreas Boman
Quoted 7 lines · Con Kolivas
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?
Quoted 5 lines
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)
Quoted 4 lines
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.

Quoted 8 lines

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.

Quoted 1 line

Sigh, scheduling is a _bitch_.

Indeed

Con.

Con Kolivas

author

2003-06-19 07:57 UTC #10 lore raw

Quoted 32 lines · Con Kolivas

Quoted 22 lines · Mike Galbraith
Quoted 16 lines · Con Kolivas
Quoted 9 lines · Andreas Boman
Quoted 7 lines · Con Kolivas
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?
Quoted 5 lines
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)
Quoted 4 lines
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.
Quoted 8 lines
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.

Quoted 9 lines

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

Nick Piggin

2003-06-19 07:19 UTC #11 lore raw

In reply to Mike Galbraith

Quoted 21 lines · Mike Galbraith

Quoted 19 lines · Con Kolivas
Quoted 4 lines · Andreas Boman
Quoted 3 lines · Con Kolivas
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
Quoted 2 lines
Quoted 2 lines
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
Quoted 4 lines
Quoted 1 line
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
Quoted 1 line
the first 5 sec or so of playback IFF make -j20 is running. On a
mostly
Quoted 2 lines
idle box (well LoadAvg 3 or so is mostly idle isnt it? ;) desktop switching doesnt cause skips anymore 8)

Quoted 8 lines

Quoted 3 lines
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? ;)

Mike Galbraith

2003-06-19 08:33 UTC #12 lore raw

Quoted 26 lines · Nick Piggin

Quoted 24 lines · Mike Galbraith
Quoted 15 lines · Con Kolivas
Quoted 8 lines · Andreas Boman
Quoted 6 lines · Con Kolivas
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?
Quoted 5 lines
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)
Quoted 3 lines
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.

Quoted 8 lines

Quoted 1 line
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.

Quoted 4 lines

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.

Quoted 1 line

Am I rambling? ;)

IMHO, the more people who ruminate/ramble on this very hard subject the better.

-Mike

Nick Piggin

2003-06-19 08:44 UTC #13 lore raw

Quoted 11 lines · Mike Galbraith

Quoted 9 lines · Nick Piggin
Quoted 4 lines · Mike Galbraith
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.

Quoted 8 lines

Quoted 5 lines
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.

Quoted 8 lines

Quoted 5 lines
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.

Nick Piggin

2003-06-19 08:46 UTC #14 lore raw

Quoted 24 lines · Nick Piggin

Quoted 20 lines · Mike Galbraith
Quoted 15 lines · Nick Piggin
Quoted 4 lines · Mike Galbraith
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...

Quoted 6 lines

Quoted 1 line
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...

Mike Galbraith

2003-06-19 09:00 UTC #15 lore raw

In reply to Nick Piggin

Quoted 20 lines · Nick Piggin

Quoted 18 lines · Mike Galbraith
Quoted 14 lines · Nick Piggin
Quoted 4 lines · Mike Galbraith
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...

Quoted 5 lines

Quoted 1 line
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.

Quoted 6 lines

Quoted 6 lines
Quoted 4 lines
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?

Quoted 6 lines

Quoted 1 line
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.

Quoted 4 lines

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.

Quoted 1 line

in

(messagus interruptus?)

-Mike

Robert Love

2003-06-18 17:51 UTC #16 lore raw

In reply to Con Kolivas

Quoted 3 lines · Con Kolivas

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