1 ==========================
2 Real-Time group scheduling
3 ==========================
4
5 .. CONTENTS
6
7 0. WARNING
8 1. Overview
9 1.1 The problem
10 1.2 The solution
11 2. The interface
12 2.1 System-wide settings
13 2.2 Default behaviour
14 2.3 Basis for grouping tasks
15 3. Future plans
16
17
18 0. WARNING
19 ==========
20
21 Fiddling with these settings can result in an
22 root only and assumes root knows what he is d
23
24 Most notable:
25
26 * very small values in sched_rt_period_us can
27 system when the period is smaller than eith
28 resolution, or the time it takes to handle
29
30 * very small values in sched_rt_runtime_us ca
31 system when the runtime is so small the sys
32 forward progress (NOTE: the migration threa
33 are real-time processes).
34
35 1. Overview
36 ===========
37
38
39 1.1 The problem
40 ---------------
41
42 Real-time scheduling is all about determinism,
43 the amount of bandwidth (eg. CPU time) being c
44 multiple groups of real-time tasks, each group
45 of the CPU time available. Without a minimum
46 obviously fall short. A fuzzy upper limit is o
47 relied upon. Which leaves us with just the sin
48
49 1.2 The solution
50 ----------------
51
52 CPU time is divided by means of specifying how
53 in a given period. We allocate this "run time"
54 the other real-time groups will not be permitt
55
56 Any time not allocated to a real-time group wi
57 tasks (SCHED_OTHER). Any allocated run time no
58 SCHED_OTHER.
59
60 Let's consider an example: a frame fixed real-
61 frames a second, which yields a period of 0.04
62 have to play some music and respond to input,
63 time dedicated for the graphics. We can then g
64 * 0.04s = 0.032s.
65
66 This way the graphics group will have a 0.04s
67 limit. Now if the audio thread needs to refill
68 needs only about 3% CPU time to do so, it can
69 0.00015s. So this group can be scheduled with
70 of 0.00015s.
71
72 The remaining CPU time will be used for user i
73 real-time tasks have explicitly allocated the
74 their tasks, buffer underruns in the graphics
75
76 NOTE: the above example is not fully implement
77 lack an EDF scheduler to make non-uniform peri
78
79
80 2. The Interface
81 ================
82
83
84 2.1 System wide settings
85 ------------------------
86
87 The system wide settings are configured under
88
89 /proc/sys/kernel/sched_rt_period_us:
90 The scheduling period that is equivalent to
91
92 /proc/sys/kernel/sched_rt_runtime_us:
93 A global limit on how much time real-time sc
94 less or equal to the period_us, as it denote
95 period_us for the real-time tasks. Even with
96 this will limit time reserved to real-time p
97 CONFIG_RT_GROUP_SCHED=y it signifies the tot
98 real-time groups.
99
100 * Time is specified in us because the interf
101 operating range from 1us to about 35 minut
102 * sched_rt_period_us takes values from 1 to
103 * sched_rt_runtime_us takes values from -1 t
104 * A run time of -1 specifies runtime == peri
105
106
107 2.2 Default behaviour
108 ---------------------
109
110 The default values for sched_rt_period_us (100
111 sched_rt_runtime_us (950000 or 0.95s). This g
112 SCHED_OTHER (non-RT tasks). These defaults wer
113 real-time tasks will not lock up the machine b
114 it. By setting runtime to -1 you'd get the ol
115
116 By default all bandwidth is assigned to the ro
117 period from /proc/sys/kernel/sched_rt_period_u
118 want to assign bandwidth to another group, red
119 and assign some or all of the difference to an
120
121 Real-time group scheduling means you have to a
122 bandwidth to the group before it will accept r
123 not be able to run real-time tasks as any user
124 done that, even if the user has the rights to
125 priority!
126
127
128 2.3 Basis for grouping tasks
129 ----------------------------
130
131 Enabling CONFIG_RT_GROUP_SCHED lets you explic
132 CPU bandwidth to task groups.
133
134 This uses the cgroup virtual file system and "
135 to control the CPU time reserved for each cont
136
137 For more information on working with control g
138 Documentation/admin-guide/cgroup-v1/cgroups.rs
139
140 Group settings are checked against the followi
141 configuration schedulable:
142
143 \Sum_{i} runtime_{i} / global_period <= glo
144
145 For now, this can be simplified to just the fo
146
147 \Sum_{i} runtime_{i} <= global_runtime
148
149
150 3. Future plans
151 ===============
152
153 There is work in progress to make the scheduli
154 ("<cgroup>/cpu.rt_period_us") configurable as
155
156 The constraint on the period is that a subgrou
157 equal period to its parent. But realistically
158 as its prone to starvation without deadline sc
159
160 Consider two sibling groups A and B; both have
161 period is twice the length of B's.
162
163 * group A: period=100000us, runtime=50000us
164
165 - this runs for 0.05s once every 0.1s
166
167 * group B: period= 50000us, runtime=25000us
168
169 - this runs for 0.025s twice every 0.1
170
171 This means that currently a while (1) loop in
172 B and can starve B's tasks (assuming they are
173 period.
174
175 The next project will be SCHED_EDF (Earliest D
176 full deadline scheduling to the linux kernel.
177 groups and treating end of the period as a dea
178 get their allocated time.
179
180 Implementing SCHED_EDF might take a while to c
181 the biggest challenge as the current linux PI
182 the limited static priority levels 0-99. With
183 do deadline inheritance (since priority is inv
184 deadline delta (deadline - now)).
185
186 This means the whole PI machinery will have to
187 the most complex pieces of code we have.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.