login
Search
2.4 kernel maintainer [story] Willy Tarreau ran some tests to compare Con Kolivas [interview]'s Staircase Deadline CPU scheduler [story] with Ingo Molnar [interview]'s new Completely Fair Scheduler [story]. He summarized his experiences:
"I think that CFS is based on a more promising concept but is less mature and is dangerous right now with certain workloads. SD shows some strange behaviours like not using all CPU available and a little jerkyness, but is more robust and may be the less risky solution for a first step towards a better scheduler in mainline, but it may also probably be the last O(1) scheduler, which may be replaced sometime later when CFS (or any other one) shows at the same time the smoothness of CFS and the robustness of SD."
Some debate was raised by logic added since CFS version 3 to automatically nice the X process for better GUI responsiveness. The CFS changelog comment labels the change as a usibility fix explaining, "automatic renicing of kernel threads such as keventd, OOM tasks and tasks doing privileged hardware access (such as Xorg)." Ingo posted a standalone patch demonstrating how these processes are detected and automatically niced, offering it for inclusion into Con's Staircase scheduler. Willy concurred that it was a good idea, "I think it could be a good idea since you recommend to renice X with SD. Most of the problem users are facing with renicing X is that they need to change their configs or scripts. If the kernel can reliably detect X and handle it differently, why not do it ?" Con was less convinced, "hmm well I have tried my very best to do all the changes without changing 'policy' as much as possible since that trips over so many emotive issues that noone can agree on, and I don't have a strong opinion on this as I thought it would be better for it to be a config option for X in userspace instead. Either way it needs to be turned on/off by admin and doing it by default in the kernel is... not universally accepted as good."
From: Willy Tarreau [email blocked] To: Ingo Molnar [email blocked], Con Kolivas [email blocked] Subject: [REPORT] cfs-v4 vs sd-0.44 Date: Sat, 21 Apr 2007 14:12:35 +0200 Hi Ingo, Hi Con, I promised to perform some tests on your code. I'm short in time right now, but I observed behaviours that should be commented on. 1) machine : dual athlon 1533 MHz, 1G RAM, kernel 2.6.21-rc7 + either scheduler Test: ./ocbench -R 250000 -S 750000 -x 8 -y 8 ocbench: http://linux.1wt.eu/sched/ 2) SD-0.44 Feels good, but becomes jerky at moderately high loads. I've started 64 ocbench with a 250 ms busy loop and 750 ms sleep time. The system always responds correctly but under X, mouse jumps quite a bit and typing in xterm or even text console feels slightly jerky. The CPU is not completely used, and the load varies a lot (see below). However, the load is shared equally between all 64 ocbench, and they do not deviate even after 4000 iterations. X uses less than 1% CPU during those tests. Here's the vmstat output : willy@pcw:~$ vmstat 1 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 0 0 0 0 919856 6648 57788 0 0 22 2 4 148 31 49 20 0 0 0 0 919856 6648 57788 0 0 0 0 2 285 32 50 19 28 0 0 0 919836 6648 57788 0 0 0 0 0 331 24 40 36 64 0 0 0 919836 6648 57788 0 0 0 0 1 618 23 40 37 65 0 0 0 919836 6648 57788 0 0 0 0 0 571 21 36 43 35 0 0 0 919836 6648 57788 0 0 0 0 3 382 32 50 18 2 0 0 0 919836 6648 57788 0 0 0 0 0 308 37 61 2 8 0 0 0 919836 6648 57788 0 0 0 0 1 533 36 65 0 32 0 0 0 919768 6648 57788 0 0 0 0 93 706 33 62 5 62 0 0 0 919712 6648 57788 0 0 0 0 65 617 32 54 13 63 0 0 0 919712 6648 57788 0 0 0 0 1 569 28 48 23 40 0 0 0 919712 6648 57788 0 0 0 0 0 427 26 50 24 4 0 0 0 919712 6648 57788 0 0 0 0 1 382 29 48 23 4 0 0 0 919712 6648 57788 0 0 0 0 0 383 34 65 0 14 0 0 0 919712 6648 57788 0 0 0 0 1 769 39 61 0 40 0 0 0 919712 6648 57788 0 0 0 0 0 384 37 52 11 54 0 0 0 919712 6648 57788 0 0 0 0 1 715 31 60 8 58 0 2 0 919712 6648 57788 0 0 0 0 1 611 34 65 0 41 0 0 0 919712 6648 57788 0 0 0 0 19 395 28 45 27 0 0 0 0 919712 6648 57788 0 0 0 0 31 421 23 32 45 0 0 0 0 919712 6648 57788 0 0 0 0 31 328 34 44 22 29 0 0 0 919712 6648 57788 0 0 0 0 34 369 32 43 25 65 0 0 0 919712 6648 57788 0 0 0 0 31 410 24 35 40 47 0 1 0 919712 6648 57788 0 0 0 0 42 538 25 39 35 3) CFS-v4 Feels even better, mouse movements are very smooth even under high load. I noticed that X gets reniced to -19 with this scheduler. I've not looked at the code yet but this looked suspicious to me. I've reniced it to 0 and it did not change any behaviour. Still very good. The 64 ocbench share equal CPU time and show exact same progress after 2000 iterations. The CPU load is more smoothly spread according to vmstat, and there's no idle (see below). BUT I now think it was wrong to let new processes start with no timeslice at all, because it can take tens of seconds to start a new process when only 64 ocbench are there. Simply starting "killall ocbench" takes about 10 seconds. On a smaller machine (VIA C3-533), it took me more than one minute to do "su -", even from console, so that's not X. BTW, X uses less than 1% CPU during those tests. willy@pcw:~$ vmstat 1 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 12 0 2 0 922120 6532 57540 0 0 299 29 31 386 17 27 57 12 0 2 0 922096 6532 57556 0 0 0 0 1 776 37 63 0 14 0 2 0 922096 6532 57556 0 0 0 0 1 782 35 65 0 13 0 1 0 922096 6532 57556 0 0 0 0 0 782 38 62 0 14 0 1 0 922096 6532 57556 0 0 0 0 1 782 36 64 0 13 0 1 0 922096 6532 57556 0 0 0 0 2 785 38 62 0 13 0 1 0 922096 6532 57556 0 0 0 0 1 774 35 65 0 14 0 1 0 922096 6532 57556 0 0 0 0 0 784 36 64 0 13 0 1 0 922096 6532 57556 0 0 0 0 1 767 37 63 0 13 0 1 0 922096 6532 57556 0 0 0 0 1 785 41 59 0 14 0 1 0 922096 6532 57556 0 0 0 0 0 779 38 62 0 19 0 1 0 922096 6532 57556 0 0 0 0 1 816 38 62 0 22 0 1 0 922096 6532 57556 0 0 0 0 0 817 35 65 0 19 0 1 0 922096 6532 57556 0 0 0 0 1 817 39 61 0 21 0 1 0 922096 6532 57556 0 0 0 0 0 849 36 64 0 20 0 0 0 922096 6532 57556 0 0 0 0 1 793 36 64 0 21 0 0 0 922096 6532 57556 0 0 0 0 0 815 37 63 0 19 0 0 0 922096 6532 57556 0 0 0 0 1 824 35 65 0 21 0 0 0 922096 6532 57556 0 0 0 0 0 817 35 65 0 26 0 0 0 922096 6532 57556 0 0 0 0 1 824 38 62 0 26 0 0 0 922096 6532 57556 0 0 0 0 1 817 35 65 0 26 0 0 0 922096 6532 57556 0 0 0 0 0 811 37 63 0 26 0 0 0 922096 6532 57556 0 0 0 0 1 804 34 66 0 16 0 0 0 922096 6532 57556 0 0 0 0 39 850 35 65 0 18 0 0 0 922096 6532 57556 0 0 0 0 1 801 39 61 0 4) first impressions I think that CFS is based on a more promising concept but is less mature and is dangerous right now with certain workloads. SD shows some strange behaviours like not using all CPU available and a little jerkyness, but is more robust and may be the less risky solution for a first step towards a better scheduler in mainline, but it may also probably be the last O(1) scheduler, which may be replaced sometime later when CFS (or any other one) shows at the same time the smoothness of CFS and the robustness of SD. I'm sorry not to spend more time on them right now, I hope that other people will do. Regards, Willy
From: Con Kolivas [email blocked] Subject: Re: [REPORT] cfs-v4 vs sd-0.44 Date: Sat, 21 Apr 2007 22:40:18 +1000 On Saturday 21 April 2007 22:12, Willy Tarreau wrote: > Hi Ingo, Hi Con, > > I promised to perform some tests on your code. I'm short in time right now, > but I observed behaviours that should be commented on. > > 1) machine : dual athlon 1533 MHz, 1G RAM, kernel 2.6.21-rc7 + either > scheduler Test: ./ocbench -R 250000 -S 750000 -x 8 -y 8 > ocbench: http://linux.1wt.eu/sched/ > > 2) SD-0.44 > > Feels good, but becomes jerky at moderately high loads. I've started > 64 ocbench with a 250 ms busy loop and 750 ms sleep time. The system > always responds correctly but under X, mouse jumps quite a bit and > typing in xterm or even text console feels slightly jerky. The CPU is > not completely used, and the load varies a lot (see below). However, > the load is shared equally between all 64 ocbench, and they do not > deviate even after 4000 iterations. X uses less than 1% CPU during > those tests. > > Here's the vmstat output : [snip] > 3) CFS-v4 > > Feels even better, mouse movements are very smooth even under high load. > I noticed that X gets reniced to -19 with this scheduler. I've not looked > at the code yet but this looked suspicious to me. I've reniced it to 0 > and it did not change any behaviour. Still very good. The 64 ocbench share > equal CPU time and show exact same progress after 2000 iterations. The CPU > load is more smoothly spread according to vmstat, and there's no idle (see > below). BUT I now think it was wrong to let new processes start with no > timeslice at all, because it can take tens of seconds to start a new > process when only 64 ocbench are there. Simply starting "killall ocbench" > takes about 10 seconds. On a smaller machine (VIA C3-533), it took me more > than one minute to do "su -", even from console, so that's not X. BTW, X > uses less than 1% CPU during those tests. > > willy@pcw:~$ vmstat 1 [snip] > 4) first impressions > > I think that CFS is based on a more promising concept but is less mature > and is dangerous right now with certain workloads. SD shows some strange > behaviours like not using all CPU available and a little jerkyness, but is > more robust and may be the less risky solution for a first step towards > a better scheduler in mainline, but it may also probably be the last O(1) > scheduler, which may be replaced sometime later when CFS (or any other one) > shows at the same time the smoothness of CFS and the robustness of SD. I assumed from your description that you were running X nice 0 during all this testing and left the tunables from both SD and CFS at their defaults; this tends to have the effective equivalent of "timeslice" in CFS smaller than SD. > I'm sorry not to spend more time on them right now, I hope that other > people will do. Thanks for that interesting testing you've done. The fluctuating cpu load and the apparently high idle time means there is almost certainly a bug still in the cpu accounting I do in update_cpu_clock. It looks suspicious to me already on just my first glance. Fortunately the throughput does not appear to be adversely affected on other benchmarks so I suspect it's lying about the idle time and it's not really there. Which means it's likely also accounting the cpu time wrongly. Which also means there's something I can fix and improve SD further. Great stuff, thanks! -- -ck
From: Willy Tarreau [email blocked] Subject: Re: [REPORT] cfs-v4 vs sd-0.44 Date: Sat, 21 Apr 2007 15:02:16 +0200 On Sat, Apr 21, 2007 at 10:40:18PM +1000, Con Kolivas wrote: > On Saturday 21 April 2007 22:12, Willy Tarreau wrote: > > I assumed from your description that you were running X nice 0 during all this Yes, that's what I did. > testing and left the tunables from both SD and CFS at their defaults; yes too because I don't have enough time to try many combinations this week-end. > this > tends to have the effective equivalent of "timeslice" in CFS smaller than SD. If you look at the CS column in vmstat, you'll see that there's about twice as many context switches with CFS than with SD, meaning the average timeslice would be about twice as short with CFS. But my impression is that some tasks occasionally get very long timeslices with SD while this never happens with CFS, hence the very smooth versus jerky feeling which cannot be explained by just halved timeslices alone. > > I'm sorry not to spend more time on them right now, I hope that other > > people will do. > > Thanks for that interesting testing you've done. The fluctuating cpu load and > the apparently high idle time means there is almost certainly a bug still in > the cpu accounting I do in update_cpu_clock. It looks suspicious to me > already on just my first glance. Fortunately the throughput does not appear > to be adversely affected on other benchmarks so I suspect it's lying about > the idle time and it's not really there. Which means it's likely also > accounting the cpu time wrongly. It is possible that only measurement is wrong because the time was evenly distributed among the 64 processes. Maybe the fix could also prevent some tasks from occasionally stealing one slice and reduce the jerkiness feeling. Anyway, it's just a bit jerky, no more freezes as we've known for years ;-) > Which also means there's something I can fix and improve SD further. > Great stuff, thanks! You're welcome ! Cheers, Willy
From: Ingo Molnar [email blocked] Subject: Re: [REPORT] cfs-v4 vs sd-0.44 Date: Sat, 21 Apr 2007 17:46:14 +0200 * Willy Tarreau [email blocked] wrote: > I promised to perform some tests on your code. I'm short in time right > now, but I observed behaviours that should be commented on. thanks for the feedback! > 3) CFS-v4 > > Feels even better, mouse movements are very smooth even under high > load. I noticed that X gets reniced to -19 with this scheduler. I've > not looked at the code yet but this looked suspicious to me. I've > reniced it to 0 and it did not change any behaviour. Still very > good. The 64 ocbench share equal CPU time and show exact same > progress after 2000 iterations. The CPU load is more smoothly spread > according to vmstat, and there's no idle (see below). BUT I now > think it was wrong to let new processes start with no timeslice at > all, because it can take tens of seconds to start a new process when > only 64 ocbench are there. [...] ok, i'll modify that portion and add back the 50%/50% parent/child CPU time sharing approach again. (which CFS had in -v1) That should not change the rest of your test and should improve the task startup characteristics. Ingo
From: Willy Tarreau [email blocked] Subject: Re: [REPORT] cfs-v4 vs sd-0.44 Date: Sat, 21 Apr 2007 18:18:18 +0200 On Sat, Apr 21, 2007 at 05:46:14PM +0200, Ingo Molnar wrote: > > * Willy Tarreau wrote: > > > I promised to perform some tests on your code. I'm short in time right > > now, but I observed behaviours that should be commented on. > > thanks for the feedback! > > > 3) CFS-v4 > > > > Feels even better, mouse movements are very smooth even under high > > load. I noticed that X gets reniced to -19 with this scheduler. I've > > not looked at the code yet but this looked suspicious to me. I've > > reniced it to 0 and it did not change any behaviour. Still very > > good. The 64 ocbench share equal CPU time and show exact same > > progress after 2000 iterations. The CPU load is more smoothly spread > > according to vmstat, and there's no idle (see below). BUT I now > > think it was wrong to let new processes start with no timeslice at > > all, because it can take tens of seconds to start a new process when > > only 64 ocbench are there. [...] > > ok, i'll modify that portion and add back the 50%/50% parent/child CPU > time sharing approach again. (which CFS had in -v1) That should not > change the rest of your test and should improve the task startup > characteristics. If you remember, with 50/50, I noticed some difficulties to fork many processes. I think that during a fork(), the parent has a higher probability of forking other processes than the child. So at least, we should use something like 67/33 or 75/25 for parent/child. There are many shell-scripts out there doing a lot of fork(), and it should be reasonable to let them keep some CPU to continue to work. Also, I believe that (in shells), most forked processes do not even consume a full timeslice (eg: $(uname -n) is very fast). This means that assigning them with a shorter one will not hurt them while preserving the shell's performance against CPU hogs. Willy
From: Linus Torvalds [email blocked] Subject: Re: [REPORT] cfs-v4 vs sd-0.44 Date: Sat, 21 Apr 2007 09:34:07 -0700 (PDT) On Sat, 21 Apr 2007, Willy Tarreau wrote: > > If you remember, with 50/50, I noticed some difficulties to fork many > processes. I think that during a fork(), the parent has a higher probability > of forking other processes than the child. So at least, we should use > something like 67/33 or 75/25 for parent/child. It would be even better to simply have the rule: - child gets almost no points at startup - but when a parent does a "waitpid()" call and blocks, it will spread out its points to the childred (the "vfork()" blocking is another case that is really the same). This is a very special kind of "priority inversion" logic: you give higher priority to the things you wait for. Not because of holding any locks, but simply because a blockign waitpid really is a damn big hint that "ok, the child now works for the parent". Linus
From: Ingo Molnar [email blocked] Subject: Re: [REPORT] cfs-v4 vs sd-0.44 Date: Sat, 21 Apr 2007 18:53:47 +0200 * Linus Torvalds wrote: > It would be even better to simply have the rule: > - child gets almost no points at startup > - but when a parent does a "waitpid()" call and blocks, it will spread > out its points to the childred (the "vfork()" blocking is another case > that is really the same). > > This is a very special kind of "priority inversion" logic: you give > higher priority to the things you wait for. Not because of holding any > locks, but simply because a blockign waitpid really is a damn big hint > that "ok, the child now works for the parent". yeah. One problem i can see with the implementation of this though is that shells typically do nonspecific waits - for example bash does this on a simple 'ls' command: 21310 clone(child_stack=0, ...) = 21399 ... 21399 execve("/bin/ls", ... 21310 waitpid(-1, <unfinished ...> the PID is -1 so we dont actually know which task we are waiting for. We could use the first entry from the p->children list, but that looks too specific of a hack to me. It should catch most of the synchronous-helper-task cases though. Ingo
From: Con Kolivas [email blocked] Subject: Re: [REPORT] cfs-v4 vs sd-0.44 Date: Sun, 22 Apr 2007 01:55:20 +1000 On Saturday 21 April 2007 22:12, Willy Tarreau wrote: > I promised to perform some tests on your code. I'm short in time right now, > but I observed behaviours that should be commented on. > Feels even better, mouse movements are very smooth even under high load. > I noticed that X gets reniced to -19 with this scheduler. I've not looked > at the code yet but this looked suspicious to me. Looks like this code does it: +int sysctl_sched_privileged_nice_level __read_mostly = -19; allows anything that sets sched_privileged_task one way or another gets nice -19, and this is enabled by default. --- linux-cfs-2.6.20.7.q.orig/arch/i386/kernel/ioport.c +++ linux-cfs-2.6.20.7.q/arch/i386/kernel/ioport.c + if (turn_on) { + if (!capable(CAP_SYS_RAWIO)) + return -EPERM; + /* + * Task will be accessing hardware IO ports, + * mark it as special with the scheduler too: + */ + sched_privileged_task(current); + } presumably that selects out X as a privileged task... and sets it to nice -19 by default. -- -ck
From: Ingo Molnar [email blocked] Subject: Re: [REPORT] cfs-v4 vs sd-0.44 Date: Sat, 21 Apr 2007 18:00:08 +0200 * Con Kolivas [email blocked] wrote: > > Feels even better, mouse movements are very smooth even under high > > load. I noticed that X gets reniced to -19 with this scheduler. > > I've not looked at the code yet but this looked suspicious to me. > > I've reniced it to 0 and it did not change any behaviour. Still > > very good. > > Looks like this code does it: > > +int sysctl_sched_privileged_nice_level __read_mostly = -19; correct. Note that Willy reniced X back to 0 so it had no relevance on his test. Also note that i pointed this change out in the -v4 CFS announcement: || Changes since -v3: || || - usability fix: automatic renicing of kernel threads such as || keventd, OOM tasks and tasks doing privileged hardware access || (such as Xorg). i've attached it below in a standalone form, feel free to put it into SD! :) Ingo
From: Willy Tarreau [email blocked] Subject: Re: [REPORT] cfs-v4 vs sd-0.44 Date: Sat, 21 Apr 2007 18:12:08 +0200 On Sat, Apr 21, 2007 at 06:00:08PM +0200, Ingo Molnar wrote: > > * Con Kolivas [email blocked] wrote: > > > > Feels even better, mouse movements are very smooth even under high > > > load. I noticed that X gets reniced to -19 with this scheduler. > > > I've not looked at the code yet but this looked suspicious to me. > > > I've reniced it to 0 and it did not change any behaviour. Still > > > very good. > > > > Looks like this code does it: > > > > +int sysctl_sched_privileged_nice_level __read_mostly = -19; > > correct. Note that Willy reniced X back to 0 so it had no relevance on > his test. Anyway, my X was mostly unused (below 1% CPU), which was my intent when replacing glxgears by ocbench. We have not settled yet about how to handle the special case for X. Let's at least try to get the best schedulers without this problem, then see how to make them behave the best taking X into account. > Also note that i pointed this change out in the -v4 CFS > announcement: > > || Changes since -v3: > || > || - usability fix: automatic renicing of kernel threads such as > || keventd, OOM tasks and tasks doing privileged hardware access > || (such as Xorg). > > i've attached it below in a standalone form, feel free to put it into > SD! :) Con, I think it could be a good idea since you recommend to renice X with SD. Most of the problem users are facing with renicing X is that they need to change their configs or scripts. If the kernel can reliably detect X and handle it differently, why not do it ? It makes me think that this hint might be used to set some flags in the task struct in order to apply different processing than just renicing. It is indeed possible that nice is not the best solution and that something else would be even better (eg: longer timeslices, but not changing priority in the queues). Just an idea anyway. OK, back to work ;-) Willy
From: Con Kolivas [email blocked] Subject: Re: [REPORT] cfs-v4 vs sd-0.44 Date: Sun, 22 Apr 2007 09:59:34 +1000 On Sunday 22 April 2007 02:00, Ingo Molnar wrote: > * Con Kolivas [email blocked] wrote: > > > Feels even better, mouse movements are very smooth even under high > > > load. I noticed that X gets reniced to -19 with this scheduler. > > > I've not looked at the code yet but this looked suspicious to me. > > > I've reniced it to 0 and it did not change any behaviour. Still > > > very good. > > > > Looks like this code does it: > > > > +int sysctl_sched_privileged_nice_level __read_mostly = -19; > > correct. Oh I definitely was not advocating against renicing X, I just suspect that virtually all the users who gave glowing reports to CFS comparing it to SD had no idea it had reniced X to -19 behind their back and that they were comparing it to SD running X at nice 0. I think had they been comparing CFS with X nice -19 to SD running nice -10 in this interactivity soft and squishy comparison land their thoughts might have been different. I missed it in the announcement and had to go looking in the code since Willy just kinda tripped over it unwittingly as well. > Note that Willy reniced X back to 0 so it had no relevance on > his test. Oh yes I did notice that, but since the array swap is the remaining longest deadline in SD which would cause noticeable jerks, renicing X on SD by default would make the experience very different since reniced tasks do much better over array swaps compared to non niced tasks. I really should go and make the whole thing one circular list and blow away the array swap (if I can figure out how to do it). > Also note that i pointed this change out in the -v4 CFS > > announcement: > || Changes since -v3: > || > || - usability fix: automatic renicing of kernel threads such as > || keventd, OOM tasks and tasks doing privileged hardware access > || (such as Xorg). Reading the changelog in the gloss-over fashion that I unfortunately did, even I missed it. > i've attached it below in a standalone form, feel free to put it into > SD! :) Hmm well I have tried my very best to do all the changes without changing "policy" as much as possible since that trips over so many emotive issues that noone can agree on, and I don't have a strong opinion on this as I thought it would be better for it to be a config option for X in userspace instead. Either way it needs to be turned on/off by admin and doing it by default in the kernel is... not universally accepted as good. What else accesses ioports that can get privileged nice levels? Does this make it relatively exploitable just by poking an ioport? > Ingo > > --- > arch/i386/kernel/ioport.c | 13 ++++++++++--- > arch/x86_64/kernel/ioport.c | 8 ++++++-- > drivers/block/loop.c | 5 ++++- > include/linux/sched.h | 7 +++++++ > kernel/sched.c | 40 Thanks for the patch. I'll consider it. Since end users are testing this in fuzzy interactivity land I may simply be forced to do this just for comparisons to be meaningful between CFS and SD otherwise they're not really comparing them on a level playing field. I had almost given up SD for dead meat with all the momentum CFS had gained... until recently. -- -ck
Again CPU schedulers. How
Again CPU schedulers. How about writing a good disk scheduler (ie. one with *write* scheduling)?
Man, you are so right! It
Man, you are so right! It hurts when you are "watching" movie with file copying in the background. Glory to a man that will write good I/O scheduler with write scheduling - thats one of the important things GNU/Linux needs as a desktop system.
Easier said than done
Why don't you try to write one (disk scheduler) and see how far you can go ?
Leave the guys alone and let them do what they do best : a cpu scheduler.
Auto-renice? Stupid and broken
Nice value is a static variable that is set by the USER. The kernel could give *dynamic* boosting to certain processes, but never should change the nice value behind user's back!
How stupid and broken it is? I can't believe Ingo went for that.
Re: Auto-renice? Stupid and broken
It may sound stupid for a production scheduler, but right now, CFS is experimental, and if many people always complain about the same problems and some known tricks are known, it's acceptable to help them run the tests under optimal conditions. If everything runs better with a reniced X, at least it will show that some special handling will be needed for X for the production scheduler, and it helps us find the right direction for future optimizations.
Willy