In a continued thread about how the recently merged Completely Fair Scheduler affects the nice command, Ingo Molnar offered a history of nice levels in the Linux kernel. He began by describing the three most frequent complaints he has received, first was "nice levels were always so weak under Linux that people continuously bugged me about making nice +19 tasks use up much less CPU time", second was "the fact that nice level behavior depended on the _absolute_ nice level as well, while the nice API itself is fundamentally 'relative'", and third was "negative nice levels were not 'punchy enough', so lots of people had to resort to run audio (and other multimedia) apps under RT priorities such as SCHED_FIFO."

Ingo then noted, "CFS addresses all three types of complaints". For the first complaint he noted that he "decoupled the scheduler from 'time slice' and HZ concepts (and made granularity a separate concept from nice levels) and thus CFS was able to implement better and more consistent nice +19 support: now in CFS nice +19 tasks get a HZ-independent 1.5%, instead of the variable 3%-5%-9% range they got in the old scheduler." For the second type of complaint he "made nice(1) have the same CPU utilization effect on tasks, regardless of their absolute nice levels. So on CFS, running a nice +10 and a nice +11 task has the same CPU utilization 'split' between them as running a nice -5 and a nice -4 task. (one will get 55% of the CPU, the other 45%.)" And the third type of complaint "is addressed by CFS almost automatically: stronger negative nice levels are an automatic side-effect of the recalibrated dynamic range of nice levels."

The recently merged Completely Fair Scheduler changes how the Linux kernel handles scheduling priorities set with the nice command. Ingo Molnar explained that each level of nice adds or substracts 10% of CPU utilization, "the '10% effect' is relative and cumulative: from _any_ nice level, if you go up 1 level, it's -10% CPU usage, if you go down 1 level it's +10% CPU usage." Ingo noted that with the earlier scheduler the nice level was tied to the HZ, offering three examples in which HZ is set to 100, 250, and 300, "a nice +19 task (the most commonly used nice level in practice) gets 9.1%, 3.9%, 3.1% of CPU time on the old scheduler, depending on the value of HZ. This is quite inconsistent and illogical. This HZ dependency of nice levels existed for many years, and the new scheduler solves that inconsistency - every nice level will get the same amount of time, regardless of HZ."

Ingo went on to offer a table comparing positive nice values to the percentage of the CPU that a process gets in relation to a 'nice 0' process: "nice 0: 100.00%; nice 1: 80.00%; nice 2: 64.10%; nice 3: 51.28%; nice 4: 40.98%; nice 5: 32.78%; nice 6: 26.24%; nice 7: 21.00%; nice 8: 16.77%; nice 9: 13.42%; nice 10: 10.74%; nice 11: 8.59%; nice 12: 6.87%; nice 13: 5.50%; nice 14: 4.39%; nice 15: 3.51%; nice 16: 2.81%; nice 17: 2.25%; nice 18: 1.80%; nice 19: 1.44%". He offered another table comparing negative nice values to a 'nice -20' process: "nice 0: 1.15%; nice -1: 1.44%; nice -2: 1.80%; nice -3: 2.25%; nice -4: 2.81%; nice -5: 3.51%; nice -6: 4.39%; nice -7: 5.50%; nice -8: 6.87%; nice -9: 8.59%; nice -10: 10.74%; nice -11: 13.42%; nice -12: 16.77%; nice -13: 21.00%; nice -14: 26.24%; nice -15: 32.78%; nice -16: 40.98%; nice -17: 51.28%; nice -18: 64.10%; nice -19: 80.00%; nice -20: 100.00%"