1 =====================
2 Scheduler Nice Design
3 =====================
4
5 This document explains the thinking about the
6 nice-levels implementation in the new Linux sc
7
8 Nice levels were always pretty weak under Linu
9 pestered us to make nice +19 tasks use up much
10
11 Unfortunately that was not that easy to implem
12 scheduler, (otherwise we'd have done it long a
13 support was historically coupled to timeslice
14 units were driven by the HZ tick, so the small
15
16 In the O(1) scheduler (in 2003) we changed neg
17 much stronger than they were before in 2.4 (an
18 that change), and we also intentionally calibr
19 rule so that nice +19 level would be _exactly_
20 understand it, the timeslice graph went like t
21 alert!)::
22
23
24 A
25 \ | [timeslice length]
26 \ |
27 \ |
28 \ |
29 \ |
30 \|___100msecs
31 |^ . _
32 | ^ . _
33 | ^ . _
34 -*----------------------------------*-----> [
35 -20 | +19
36 |
37 |
38
39 So that if someone wanted to really renice tas
40 bigger hit than the normal linear rule would d
41 changing the ABI to extend priorities was disc
42
43 This approach worked to some degree for some t
44 HZ=1000 it caused 1 jiffy to be 1 msec, which
45 we felt to be a bit excessive. Excessive _not_
46 a CPU utilization, but because it causes too f
47 millisec) rescheduling. (and would thus trash
48 this was long ago when hardware was weaker and
49 people were running number crunching apps at n
50
51 So for HZ=1000 we changed nice +19 to 5msecs,
52 right minimal granularity - and this translate
53 But the fundamental HZ-sensitive property for
54 and we never got a single complaint about nice
55 terms of CPU utilization, we only got complain
56 too _strong_ :-)
57
58 To sum it up: we always wanted to make nice le
59 within the constraints of HZ and jiffies and t
60 coupling to timeslices and granularity it was
61
62 The second (less frequent but still periodical
63 about Linux's nice level support was its asymm
64 (which you can see demonstrated in the picture
65 accurately: the fact that nice level behavior
66 nice level as well, while the nice API itself
67 "relative":
68
69 int nice(int inc);
70
71 asmlinkage long sys_nice(int increment)
72
73 (the first one is the glibc API, the second on
74 Note that the 'inc' is relative to the current
75 bash's "nice" command mirror this relative API
76
77 With the old scheduler, if you for example sta
78 and another task with +2, the CPU split betwee
79 depend on the nice level of the parent shell -
80 CPU split was different than if it was at +5 o
81
82 A third complaint against Linux's nice level s
83 nice levels were not 'punchy enough', so lots
84 run audio (and other multimedia) apps under RT
85 SCHED_FIFO. But this caused other problems: SC
86 proof, and a buggy SCHED_FIFO app can also loc
87
88 The new scheduler in v2.6.23 addresses all thr
89
90 To address the first complaint (of nice levels
91 enough), the scheduler was decoupled from 'tim
92 (and granularity was made a separate concept f
93 it was possible to implement better and more c
94 support: with the new scheduler nice +19 tasks
95 1.5%, instead of the variable 3%-5%-9% range t
96 scheduler.
97
98 To address the second complaint (of nice level
99 the new scheduler makes nice(1) have the same
100 tasks, regardless of their absolute nice level
101 scheduler, running a nice +10 and a nice 11 ta
102 utilization "split" between them as running a
103 task. (one will get 55% of the CPU, the other
104 levels were changed to be "multiplicative" (or
105 it does not matter which nice level you start
106 result' will always be the same.
107
108 The third complaint (of negative nice levels n
109 and forcing audio apps to run under the more d
110 scheduling policy) is addressed by the new sch
111 automatically: stronger negative nice levels a
112 side-effect of the recalibrated dynamic range
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.