readv2: Note preadv2(..., RWF_NOWAIT) bug in BUGS section
[man-pages.git] / man7 / sched.7
blobfcc68a34f028a92526055e72e045a9b1b068ad10
1 .\" Copyright (C) 2014 Michael Kerrisk <mtk.manpages@gmail.com>
2 .\" and Copyright (C) 2014 Peter Zijlstra <peterz@infradead.org>
3 .\" and Copyright (C) 2014 Juri Lelli <juri.lelli@gmail.com>
4 .\" Various pieces from the old sched_setscheduler(2) page
5 .\"     Copyright (C) Tom Bjorkholm, Markus Kuhn & David A. Wheeler 1996-1999
6 .\"     and Copyright (C) 2007 Carsten Emde <Carsten.Emde@osadl.org>
7 .\"     and Copyright (C) 2008 Michael Kerrisk <mtk.manpages@gmail.com>
8 .\"
9 .\" %%%LICENSE_START(GPLv2+_DOC_FULL)
10 .\" This is free documentation; you can redistribute it and/or
11 .\" modify it under the terms of the GNU General Public License as
12 .\" published by the Free Software Foundation; either version 2 of
13 .\" the License, or (at your option) any later version.
14 .\"
15 .\" The GNU General Public License's references to "object code"
16 .\" and "executables" are to be interpreted as the output of any
17 .\" document formatting or typesetting system, including
18 .\" intermediate and printed output.
19 .\"
20 .\" This manual is distributed in the hope that it will be useful,
21 .\" but WITHOUT ANY WARRANTY; without even the implied warranty of
22 .\" MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
23 .\" GNU General Public License for more details.
24 .\"
25 .\" You should have received a copy of the GNU General Public
26 .\" License along with this manual; if not, see
27 .\" <http://www.gnu.org/licenses/>.
28 .\" %%%LICENSE_END
29 .\"
30 .\" Worth looking at: http://rt.wiki.kernel.org/index.php
31 .\"
32 .TH SCHED 7 2021-03-22 "Linux" "Linux Programmer's Manual"
33 .SH NAME
34 sched \- overview of CPU scheduling
35 .SH DESCRIPTION
36 Since Linux 2.6.23, the default scheduler is CFS,
37 the "Completely Fair Scheduler".
38 The CFS scheduler replaced the earlier "O(1)" scheduler.
39 .\"
40 .SS API summary
41 Linux provides the following system calls for controlling
42 the CPU scheduling behavior, policy, and priority of processes
43 (or, more precisely, threads).
44 .TP
45 .BR nice (2)
46 Set a new nice value for the calling thread,
47 and return the new nice value.
48 .TP
49 .BR getpriority (2)
50 Return the nice value of a thread, a process group,
51 or the set of threads owned by a specified user.
52 .TP
53 .BR setpriority (2)
54 Set the nice value of a thread, a process group,
55 or the set of threads owned by a specified user.
56 .TP
57 .BR sched_setscheduler (2)
58 Set the scheduling policy and parameters of a specified thread.
59 .TP
60 .BR sched_getscheduler (2)
61 Return the scheduling policy of a specified thread.
62 .TP
63 .BR sched_setparam (2)
64 Set the scheduling parameters of a specified thread.
65 .TP
66 .BR sched_getparam (2)
67 Fetch the scheduling parameters of a specified thread.
68 .TP
69 .BR sched_get_priority_max (2)
70 Return the maximum priority available in a specified scheduling policy.
71 .TP
72 .BR sched_get_priority_min (2)
73 Return the minimum priority available in a specified scheduling policy.
74 .TP
75 .BR sched_rr_get_interval (2)
76 Fetch the quantum used for threads that are scheduled under
77 the "round-robin" scheduling policy.
78 .TP
79 .BR sched_yield (2)
80 Cause the caller to relinquish the CPU,
81 so that some other thread be executed.
82 .TP
83 .BR sched_setaffinity (2)
84 (Linux-specific)
85 Set the CPU affinity of a specified thread.
86 .TP
87 .BR sched_getaffinity (2)
88 (Linux-specific)
89 Get the CPU affinity of a specified thread.
90 .TP
91 .BR sched_setattr (2)
92 Set the scheduling policy and parameters of a specified thread.
93 This (Linux-specific) system call provides a superset of the functionality of
94 .BR sched_setscheduler (2)
95 and
96 .BR sched_setparam (2).
97 .TP
98 .BR sched_getattr (2)
99 Fetch the scheduling policy and parameters of a specified thread.
100 This (Linux-specific) system call provides a superset of the functionality of
101 .BR sched_getscheduler (2)
103 .BR sched_getparam (2).
105 .SS Scheduling policies
106 The scheduler is the kernel component that decides which runnable thread
107 will be executed by the CPU next.
108 Each thread has an associated scheduling policy and a \fIstatic\fP
109 scheduling priority,
110 .IR sched_priority .
111 The scheduler makes its decisions based on knowledge of the scheduling
112 policy and static priority of all threads on the system.
114 For threads scheduled under one of the normal scheduling policies
115 (\fBSCHED_OTHER\fP, \fBSCHED_IDLE\fP, \fBSCHED_BATCH\fP),
116 \fIsched_priority\fP is not used in scheduling
117 decisions (it must be specified as 0).
119 Processes scheduled under one of the real-time policies
120 (\fBSCHED_FIFO\fP, \fBSCHED_RR\fP) have a
121 \fIsched_priority\fP value in the range 1 (low) to 99 (high).
122 (As the numbers imply, real-time threads always have higher priority
123 than normal threads.)
124 Note well: POSIX.1 requires an implementation to support only a
125 minimum 32 distinct priority levels for the real-time policies,
126 and some systems supply just this minimum.
127 Portable programs should use
128 .BR sched_get_priority_min (2)
130 .BR sched_get_priority_max (2)
131 to find the range of priorities supported for a particular policy.
133 Conceptually, the scheduler maintains a list of runnable
134 threads for each possible \fIsched_priority\fP value.
135 In order to determine which thread runs next, the scheduler looks for
136 the nonempty list with the highest static priority and selects the
137 thread at the head of this list.
139 A thread's scheduling policy determines
140 where it will be inserted into the list of threads
141 with equal static priority and how it will move inside this list.
143 All scheduling is preemptive: if a thread with a higher static
144 priority becomes ready to run, the currently running thread
145 will be preempted and
146 returned to the wait list for its static priority level.
147 The scheduling policy determines the
148 ordering only within the list of runnable threads with equal static
149 priority.
150 .SS SCHED_FIFO: First in-first out scheduling
151 \fBSCHED_FIFO\fP can be used only with static priorities higher than
152 0, which means that when a \fBSCHED_FIFO\fP thread becomes runnable,
153 it will always immediately preempt any currently running
154 \fBSCHED_OTHER\fP, \fBSCHED_BATCH\fP, or \fBSCHED_IDLE\fP thread.
155 \fBSCHED_FIFO\fP is a simple scheduling
156 algorithm without time slicing.
157 For threads scheduled under the
158 \fBSCHED_FIFO\fP policy, the following rules apply:
159 .IP 1) 3
160 A running \fBSCHED_FIFO\fP thread that has been preempted by another thread of
161 higher priority will stay at the head of the list for its priority and
162 will resume execution as soon as all threads of higher priority are
163 blocked again.
164 .IP 2)
165 When a blocked \fBSCHED_FIFO\fP thread becomes runnable, it
166 will be inserted at the end of the list for its priority.
167 .IP 3)
168 If a call to
169 .BR sched_setscheduler (2),
170 .BR sched_setparam (2),
171 .BR sched_setattr (2),
172 .BR pthread_setschedparam (3),
174 .BR pthread_setschedprio (3)
175 changes the priority of the running or runnable
176 .B SCHED_FIFO
177 thread identified by
178 .I pid
179 the effect on the thread's position in the list depends on
180 the direction of the change to threads priority:
182 .IP \(bu 3
183 If the thread's priority is raised,
184 it is placed at the end of the list for its new priority.
185 As a consequence,
186 it may preempt a currently running thread with the same priority.
187 .IP \(bu
188 If the thread's priority is unchanged,
189 its position in the run list is unchanged.
190 .IP \(bu
191 If the thread's priority is lowered,
192 it is placed at the front of the list for its new priority.
195 According to POSIX.1-2008,
196 changes to a thread's priority (or policy) using any mechanism other than
197 .BR pthread_setschedprio (3)
198 should result in the thread being placed at the end of
199 the list for its priority.
200 .\" In 2.2.x and 2.4.x, the thread is placed at the front of the queue
201 .\" In 2.0.x, the Right Thing happened: the thread went to the back -- MTK
202 .IP 4)
203 A thread calling
204 .BR sched_yield (2)
205 will be put at the end of the list.
207 No other events will move a thread
208 scheduled under the \fBSCHED_FIFO\fP policy in the wait list of
209 runnable threads with equal static priority.
211 A \fBSCHED_FIFO\fP
212 thread runs until either it is blocked by an I/O request, it is
213 preempted by a higher priority thread, or it calls
214 .BR sched_yield (2).
215 .SS SCHED_RR: Round-robin scheduling
216 \fBSCHED_RR\fP is a simple enhancement of \fBSCHED_FIFO\fP.
217 Everything
218 described above for \fBSCHED_FIFO\fP also applies to \fBSCHED_RR\fP,
219 except that each thread is allowed to run only for a maximum time
220 quantum.
221 If a \fBSCHED_RR\fP thread has been running for a time
222 period equal to or longer than the time quantum, it will be put at the
223 end of the list for its priority.
224 A \fBSCHED_RR\fP thread that has
225 been preempted by a higher priority thread and subsequently resumes
226 execution as a running thread will complete the unexpired portion of
227 its round-robin time quantum.
228 The length of the time quantum can be
229 retrieved using
230 .BR sched_rr_get_interval (2).
231 .\" On Linux 2.4, the length of the RR interval is influenced
232 .\" by the process nice value -- MTK
234 .SS SCHED_DEADLINE: Sporadic task model deadline scheduling
235 Since version 3.14, Linux provides a deadline scheduling policy
236 .RB ( SCHED_DEADLINE ).
237 This policy is currently implemented using
238 GEDF (Global Earliest Deadline First)
239 in conjunction with CBS (Constant Bandwidth Server).
240 To set and fetch this policy and associated attributes,
241 one must use the Linux-specific
242 .BR sched_setattr (2)
244 .BR sched_getattr (2)
245 system calls.
247 A sporadic task is one that has a sequence of jobs, where each
248 job is activated at most once per period.
249 Each job also has a
250 .IR "relative deadline" ,
251 before which it should finish execution, and a
252 .IR "computation time" ,
253 which is the CPU time necessary for executing the job.
254 The moment when a task wakes up
255 because a new job has to be executed is called the
256 .IR "arrival time"
257 (also referred to as the request time or release time).
259 .IR "start time"
260 is the time at which a task starts its execution.
262 .I "absolute deadline"
263 is thus obtained by adding the relative deadline to the arrival time.
265 The following diagram clarifies these terms:
267 .in +4n
269 arrival/wakeup                    absolute deadline
270      |    start time                    |
271      |        |                         |
272      v        v                         v
273 -----x--------xooooooooooooooooo--------x--------x---
274               |<- comp. time ->|
275      |<------- relative deadline ------>|
276      |<-------------- period ------------------->|
280 When setting a
281 .B SCHED_DEADLINE
282 policy for a thread using
283 .BR sched_setattr (2),
284 one can specify three parameters:
285 .IR Runtime ,
286 .IR Deadline ,
288 .IR Period .
289 These parameters do not necessarily correspond to the aforementioned terms:
290 usual practice is to set Runtime to something bigger than the average
291 computation time (or worst-case execution time for hard real-time tasks),
292 Deadline to the relative deadline, and Period to the period of the task.
293 Thus, for
294 .BR SCHED_DEADLINE
295 scheduling, we have:
297 .in +4n
299 arrival/wakeup                    absolute deadline
300      |    start time                    |
301      |        |                         |
302      v        v                         v
303 -----x--------xooooooooooooooooo--------x--------x---
304               |<-- Runtime ------->|
305      |<----------- Deadline ----------->|
306      |<-------------- Period ------------------->|
310 The three deadline-scheduling parameters correspond to the
311 .IR sched_runtime ,
312 .IR sched_deadline ,
314 .IR sched_period
315 fields of the
316 .I sched_attr
317 structure; see
318 .BR sched_setattr (2).
319 These fields express values in nanoseconds.
320 .\" FIXME It looks as though specifying sched_period as 0 means
321 .\" "make sched_period the same as sched_deadline".
322 .\" This needs to be documented.
324 .IR sched_period
325 is specified as 0, then it is made the same as
326 .IR sched_deadline .
328 The kernel requires that:
330     sched_runtime <= sched_deadline <= sched_period
332 .\" See __checkparam_dl in kernel/sched/core.c
333 In addition, under the current implementation,
334 all of the parameter values must be at least 1024
335 (i.e., just over one microsecond,
336 which is the resolution of the implementation), and less than 2^63.
337 If any of these checks fails,
338 .BR sched_setattr (2)
339 fails with the error
340 .BR EINVAL .
342 The CBS guarantees non-interference between tasks, by throttling
343 threads that attempt to over-run their specified Runtime.
345 To ensure deadline scheduling guarantees,
346 the kernel must prevent situations where the set of
347 .B SCHED_DEADLINE
348 threads is not feasible (schedulable) within the given constraints.
349 The kernel thus performs an admittance test when setting or changing
350 .B SCHED_DEADLINE
351 policy and attributes.
352 This admission test calculates whether the change is feasible;
353 if it is not,
354 .BR sched_setattr (2)
355 fails with the error
356 .BR EBUSY .
358 For example, it is required (but not necessarily sufficient) for
359 the total utilization to be less than or equal to the total number of
360 CPUs available, where, since each thread can maximally run for
361 Runtime per Period, that thread's utilization is its
362 Runtime divided by its Period.
364 In order to fulfill the guarantees that are made when
365 a thread is admitted to the
366 .BR SCHED_DEADLINE
367 policy,
368 .BR SCHED_DEADLINE
369 threads are the highest priority (user controllable) threads in the
370 system; if any
371 .BR SCHED_DEADLINE
372 thread is runnable,
373 it will preempt any thread scheduled under one of the other policies.
375 A call to
376 .BR fork (2)
377 by a thread scheduled under the
378 .B SCHED_DEADLINE
379 policy fails with the error
380 .BR EAGAIN ,
381 unless the thread has its reset-on-fork flag set (see below).
384 .B SCHED_DEADLINE
385 thread that calls
386 .BR sched_yield (2)
387 will yield the current job and wait for a new period to begin.
389 .\" FIXME Calling sched_getparam() on a SCHED_DEADLINE thread
390 .\" fails with EINVAL, but sched_getscheduler() succeeds.
391 .\" Is that intended? (Why?)
393 .SS SCHED_OTHER: Default Linux time-sharing scheduling
394 \fBSCHED_OTHER\fP can be used at only static priority 0
395 (i.e., threads under real-time policies always have priority over
396 .B SCHED_OTHER
397 processes).
398 \fBSCHED_OTHER\fP is the standard Linux time-sharing scheduler that is
399 intended for all threads that do not require the special
400 real-time mechanisms.
402 The thread to run is chosen from the static
403 priority 0 list based on a \fIdynamic\fP priority that is determined only
404 inside this list.
405 The dynamic priority is based on the nice value (see below)
406 and is increased for each time quantum the thread is ready to run,
407 but denied to run by the scheduler.
408 This ensures fair progress among all \fBSCHED_OTHER\fP threads.
410 In the Linux kernel source code, the
411 .B SCHED_OTHER
412 policy is actually named
413 .BR SCHED_NORMAL .
415 .SS The nice value
416 The nice value is an attribute
417 that can be used to influence the CPU scheduler to
418 favor or disfavor a process in scheduling decisions.
419 It affects the scheduling of
420 .BR SCHED_OTHER
422 .BR SCHED_BATCH
423 (see below) processes.
424 The nice value can be modified using
425 .BR nice (2),
426 .BR setpriority (2),
428 .BR sched_setattr (2).
430 According to POSIX.1, the nice value is a per-process attribute;
431 that is, the threads in a process should share a nice value.
432 However, on Linux, the nice value is a per-thread attribute:
433 different threads in the same process may have different nice values.
435 The range of the nice value
436 varies across UNIX systems.
437 On modern Linux, the range is \-20 (high priority) to +19 (low priority).
438 On some other systems, the range is \-20..20.
439 Very early Linux kernels (Before Linux 2.0) had the range \-infinity..15.
440 .\" Linux before 1.3.36 had \-infinity..15.
441 .\" Since kernel 1.3.43, Linux has the range \-20..19.
443 The degree to which the nice value affects the relative scheduling of
444 .BR SCHED_OTHER
445 processes likewise varies across UNIX systems and
446 across Linux kernel versions.
448 With the advent of the CFS scheduler in kernel 2.6.23,
449 Linux adopted an algorithm that causes
450 relative differences in nice values to have a much stronger effect.
451 In the current implementation, each unit of difference in the
452 nice values of two processes results in a factor of 1.25
453 in the degree to which the scheduler favors the higher priority process.
454 This causes very low nice values (+19) to truly provide little CPU
455 to a process whenever there is any other
456 higher priority load on the system,
457 and makes high nice values (\-20) deliver most of the CPU to applications
458 that require it (e.g., some audio applications).
460 On Linux, the
461 .BR RLIMIT_NICE
462 resource limit can be used to define a limit to which
463 an unprivileged process's nice value can be raised; see
464 .BR setrlimit (2)
465 for details.
467 For further details on the nice value, see the subsections on
468 the autogroup feature and group scheduling, below.
470 .SS SCHED_BATCH: Scheduling batch processes
471 (Since Linux 2.6.16.)
472 \fBSCHED_BATCH\fP can be used only at static priority 0.
473 This policy is similar to \fBSCHED_OTHER\fP in that it schedules
474 the thread according to its dynamic priority
475 (based on the nice value).
476 The difference is that this policy
477 will cause the scheduler to always assume
478 that the thread is CPU-intensive.
479 Consequently, the scheduler will apply a small scheduling
480 penalty with respect to wakeup behavior,
481 so that this thread is mildly disfavored in scheduling decisions.
483 .\" The following paragraph is drawn largely from the text that
484 .\" accompanied Ingo Molnar's patch for the implementation of
485 .\" SCHED_BATCH.
486 .\" commit b0a9499c3dd50d333e2aedb7e894873c58da3785
487 This policy is useful for workloads that are noninteractive,
488 but do not want to lower their nice value,
489 and for workloads that want a deterministic scheduling policy without
490 interactivity causing extra preemptions (between the workload's tasks).
492 .SS SCHED_IDLE: Scheduling very low priority jobs
493 (Since Linux 2.6.23.)
494 \fBSCHED_IDLE\fP can be used only at static priority 0;
495 the process nice value has no influence for this policy.
497 This policy is intended for running jobs at extremely low
498 priority (lower even than a +19 nice value with the
499 .B SCHED_OTHER
501 .B SCHED_BATCH
502 policies).
504 .SS Resetting scheduling policy for child processes
505 Each thread has a reset-on-fork scheduling flag.
506 When this flag is set, children created by
507 .BR fork (2)
508 do not inherit privileged scheduling policies.
509 The reset-on-fork flag can be set by either:
510 .IP * 3
511 ORing the
512 .B SCHED_RESET_ON_FORK
513 flag into the
514 .I policy
515 argument when calling
516 .BR sched_setscheduler (2)
517 (since Linux 2.6.32);
519 .IP *
520 specifying the
521 .B SCHED_FLAG_RESET_ON_FORK
522 flag in
523 .IR attr.sched_flags
524 when calling
525 .BR sched_setattr (2).
527 Note that the constants used with these two APIs have different names.
528 The state of the reset-on-fork flag can analogously be retrieved using
529 .BR sched_getscheduler (2)
531 .BR sched_getattr (2).
533 The reset-on-fork feature is intended for media-playback applications,
534 and can be used to prevent applications evading the
535 .BR RLIMIT_RTTIME
536 resource limit (see
537 .BR getrlimit (2))
538 by creating multiple child processes.
540 More precisely, if the reset-on-fork flag is set,
541 the following rules apply for subsequently created children:
542 .IP * 3
543 If the calling thread has a scheduling policy of
544 .B SCHED_FIFO
546 .BR SCHED_RR ,
547 the policy is reset to
548 .BR SCHED_OTHER
549 in child processes.
550 .IP *
551 If the calling process has a negative nice value,
552 the nice value is reset to zero in child processes.
554 After the reset-on-fork flag has been enabled,
555 it can be reset only if the thread has the
556 .BR CAP_SYS_NICE
557 capability.
558 This flag is disabled in child processes created by
559 .BR fork (2).
561 .SS Privileges and resource limits
562 In Linux kernels before 2.6.12, only privileged
563 .RB ( CAP_SYS_NICE )
564 threads can set a nonzero static priority (i.e., set a real-time
565 scheduling policy).
566 The only change that an unprivileged thread can make is to set the
567 .B SCHED_OTHER
568 policy, and this can be done only if the effective user ID of the caller
569 matches the real or effective user ID of the target thread
570 (i.e., the thread specified by
571 .IR pid )
572 whose policy is being changed.
574 A thread must be privileged
575 .RB ( CAP_SYS_NICE )
576 in order to set or modify a
577 .BR SCHED_DEADLINE
578 policy.
580 Since Linux 2.6.12, the
581 .B RLIMIT_RTPRIO
582 resource limit defines a ceiling on an unprivileged thread's
583 static priority for the
584 .B SCHED_RR
586 .B SCHED_FIFO
587 policies.
588 The rules for changing scheduling policy and priority are as follows:
589 .IP * 3
590 If an unprivileged thread has a nonzero
591 .B RLIMIT_RTPRIO
592 soft limit, then it can change its scheduling policy and priority,
593 subject to the restriction that the priority cannot be set to a
594 value higher than the maximum of its current priority and its
595 .B RLIMIT_RTPRIO
596 soft limit.
597 .IP *
598 If the
599 .B RLIMIT_RTPRIO
600 soft limit is 0, then the only permitted changes are to lower the priority,
601 or to switch to a non-real-time policy.
602 .IP *
603 Subject to the same rules,
604 another unprivileged thread can also make these changes,
605 as long as the effective user ID of the thread making the change
606 matches the real or effective user ID of the target thread.
607 .IP *
608 Special rules apply for the
609 .BR SCHED_IDLE
610 policy.
611 In Linux kernels before 2.6.39,
612 an unprivileged thread operating under this policy cannot
613 change its policy, regardless of the value of its
614 .BR RLIMIT_RTPRIO
615 resource limit.
616 In Linux kernels since 2.6.39,
617 .\" commit c02aa73b1d18e43cfd79c2f193b225e84ca497c8
618 an unprivileged thread can switch to either the
619 .BR SCHED_BATCH
620 or the
621 .BR SCHED_OTHER
622 policy so long as its nice value falls within the range permitted by its
623 .BR RLIMIT_NICE
624 resource limit (see
625 .BR getrlimit (2)).
627 Privileged
628 .RB ( CAP_SYS_NICE )
629 threads ignore the
630 .B RLIMIT_RTPRIO
631 limit; as with older kernels,
632 they can make arbitrary changes to scheduling policy and priority.
634 .BR getrlimit (2)
635 for further information on
636 .BR RLIMIT_RTPRIO .
637 .SS Limiting the CPU usage of real-time and deadline processes
638 A nonblocking infinite loop in a thread scheduled under the
639 .BR SCHED_FIFO ,
640 .BR SCHED_RR ,
642 .BR SCHED_DEADLINE
643 policy can potentially block all other threads from accessing
644 the CPU forever.
645 Prior to Linux 2.6.25, the only way of preventing a runaway real-time
646 process from freezing the system was to run (at the console)
647 a shell scheduled under a higher static priority than the tested application.
648 This allows an emergency kill of tested
649 real-time applications that do not block or terminate as expected.
651 Since Linux 2.6.25, there are other techniques for dealing with runaway
652 real-time and deadline processes.
653 One of these is to use the
654 .BR RLIMIT_RTTIME
655 resource limit to set a ceiling on the CPU time that
656 a real-time process may consume.
658 .BR getrlimit (2)
659 for details.
661 Since version 2.6.25, Linux also provides two
662 .I /proc
663 files that can be used to reserve a certain amount of CPU time
664 to be used by non-real-time processes.
665 Reserving CPU time in this fashion allows some CPU time to be
666 allocated to (say) a root shell that can be used to kill a runaway process.
667 Both of these files specify time values in microseconds:
669 .IR /proc/sys/kernel/sched_rt_period_us
670 This file specifies a scheduling period that is equivalent to
671 100% CPU bandwidth.
672 The value in this file can range from 1 to
673 .BR INT_MAX ,
674 giving an operating range of 1 microsecond to around 35 minutes.
675 The default value in this file is 1,000,000 (1 second).
677 .IR /proc/sys/kernel/sched_rt_runtime_us
678 The value in this file specifies how much of the "period" time
679 can be used by all real-time and deadline scheduled processes
680 on the system.
681 The value in this file can range from \-1 to
682 .BR INT_MAX \-1.
683 Specifying \-1 makes the run time the same as the period;
684 that is, no CPU time is set aside for non-real-time processes
685 (which was the Linux behavior before kernel 2.6.25).
686 The default value in this file is 950,000 (0.95 seconds),
687 meaning that 5% of the CPU time is reserved for processes that
688 don't run under a real-time or deadline scheduling policy.
689 .SS Response time
690 A blocked high priority thread waiting for I/O has a certain
691 response time before it is scheduled again.
692 The device driver writer
693 can greatly reduce this response time by using a "slow interrupt"
694 interrupt handler.
695 .\" as described in
696 .\" .BR request_irq (9).
697 .SS Miscellaneous
698 Child processes inherit the scheduling policy and parameters across a
699 .BR fork (2).
700 The scheduling policy and parameters are preserved across
701 .BR execve (2).
703 Memory locking is usually needed for real-time processes to avoid
704 paging delays; this can be done with
705 .BR mlock (2)
707 .BR mlockall (2).
709 .SS The autogroup feature
710 .\" commit 5091faa449ee0b7d73bc296a93bca9540fc51d0a
711 Since Linux 2.6.38,
712 the kernel provides a feature known as autogrouping to improve interactive
713 desktop performance in the face of multiprocess, CPU-intensive
714 workloads such as building the Linux kernel with large numbers of
715 parallel build processes (i.e., the
716 .BR make (1)
717 .BR \-j
718 flag).
720 This feature operates in conjunction with the
721 CFS scheduler and requires a kernel that is configured with
722 .BR CONFIG_SCHED_AUTOGROUP .
723 On a running system, this feature is enabled or disabled via the file
724 .IR /proc/sys/kernel/sched_autogroup_enabled ;
725 a value of 0 disables the feature, while a value of 1 enables it.
726 The default value in this file is 1, unless the kernel was booted with the
727 .IR noautogroup
728 parameter.
730 A new autogroup is created when a new session is created via
731 .BR setsid (2);
732 this happens, for example, when a new terminal window is started.
733 A new process created by
734 .BR fork (2)
735 inherits its parent's autogroup membership.
736 Thus, all of the processes in a session are members of the same autogroup.
737 An autogroup is automatically destroyed when the last process
738 in the group terminates.
740 When autogrouping is enabled, all of the members of an autogroup
741 are placed in the same kernel scheduler "task group".
742 The CFS scheduler employs an algorithm that equalizes the
743 distribution of CPU cycles across task groups.
744 The benefits of this for interactive desktop performance
745 can be described via the following example.
747 Suppose that there are two autogroups competing for the same CPU
748 (i.e., presume either a single CPU system or the use of
749 .BR taskset (1)
750 to confine all the processes to the same CPU on an SMP system).
751 The first group contains ten CPU-bound processes from
752 a kernel build started with
753 .IR "make\ \-j10" .
754 The other contains a single CPU-bound process: a video player.
755 The effect of autogrouping is that the two groups will
756 each receive half of the CPU cycles.
757 That is, the video player will receive 50% of the CPU cycles,
758 rather than just 9% of the cycles,
759 which would likely lead to degraded video playback.
760 The situation on an SMP system is more complex,
761 .\" Mike Galbraith, 25 Nov 2016:
762 .\"     I'd say something more wishy-washy here, like cycles are
763 .\"     distributed fairly across groups and leave it at that, as your
764 .\"     detailed example is incorrect due to SMP fairness (which I don't
765 .\"     like much because [very unlikely] worst case scenario
766 .\"     renders a box sized group incapable of utilizing more that
767 .\"     a single CPU total).  For example, if a group of NR_CPUS
768 .\"     size competes with a singleton, load balancing will try to give
769 .\"     the singleton a full CPU of its very own.  If groups intersect for
770 .\"     whatever reason on say my quad lappy, distribution is 80/20 in
771 .\"     favor of the singleton.
772 but the general effect is the same:
773 the scheduler distributes CPU cycles across task groups such that
774 an autogroup that contains a large number of CPU-bound processes
775 does not end up hogging CPU cycles at the expense of the other
776 jobs on the system.
778 A process's autogroup (task group) membership can be viewed via the file
779 .IR /proc/[pid]/autogroup :
781 .in +4n
783 $ \fBcat /proc/1/autogroup\fP
784 /autogroup\-1 nice 0
788 This file can also be used to modify the CPU bandwidth allocated
789 to an autogroup.
790 This is done by writing a number in the "nice" range to the file
791 to set the autogroup's nice value.
792 The allowed range is from +19 (low priority) to \-20 (high priority).
793 (Writing values outside of this range causes
794 .BR write (2)
795 to fail with the error
796 .BR EINVAL .)
797 .\" FIXME .
798 .\" Because of a bug introduced in Linux 4.7
799 .\" (commit 2159197d66770ec01f75c93fb11dc66df81fd45b made changes
800 .\" that exposed the fact that autogroup didn't call scale_load()),
801 .\" it happened that *all* values in this range caused a task group
802 .\" to be further disfavored by the scheduler, with \-20 resulting
803 .\" in the scheduler mildly disfavoring the task group and +19 greatly
804 .\" disfavoring it.
806 .\" A patch was posted on 23 Nov 2016
807 .\" ("sched/autogroup: Fix 64bit kernel nice adjustment";
808 .\" check later to see in which kernel version it lands.
810 The autogroup nice setting has the same meaning as the process nice value,
811 but applies to distribution of CPU cycles to the autogroup as a whole,
812 based on the relative nice values of other autogroups.
813 For a process inside an autogroup, the CPU cycles that it receives
814 will be a product of the autogroup's nice value
815 (compared to other autogroups)
816 and the process's nice value
817 (compared to other processes in the same autogroup.
819 The use of the
820 .BR cgroups (7)
821 CPU controller to place processes in cgroups other than the
822 root CPU cgroup overrides the effect of autogrouping.
824 The autogroup feature groups only processes scheduled under
825 non-real-time policies
826 .RB ( SCHED_OTHER ,
827 .BR SCHED_BATCH ,
829 .BR SCHED_IDLE ).
830 It does not group processes scheduled under real-time and
831 deadline policies.
832 Those processes are scheduled according to the rules described earlier.
834 .SS The nice value and group scheduling
835 When scheduling non-real-time processes (i.e., those scheduled under the
836 .BR SCHED_OTHER ,
837 .BR SCHED_BATCH ,
839 .BR SCHED_IDLE
840 policies), the CFS scheduler employs a technique known as "group scheduling",
841 if the kernel was configured with the
842 .BR CONFIG_FAIR_GROUP_SCHED
843 option (which is typical).
845 Under group scheduling, threads are scheduled in "task groups".
846 Task groups have a hierarchical relationship,
847 rooted under the initial task group on the system,
848 known as the "root task group".
849 Task groups are formed in the following circumstances:
850 .IP * 3
851 All of the threads in a CPU cgroup form a task group.
852 The parent of this task group is the task group of the
853 corresponding parent cgroup.
854 .IP *
855 If autogrouping is enabled,
856 then all of the threads that are (implicitly) placed in an autogroup
857 (i.e., the same session, as created by
858 .BR setsid (2))
859 form a task group.
860 Each new autogroup is thus a separate task group.
861 The root task group is the parent of all such autogroups.
862 .IP *
863 If autogrouping is enabled, then the root task group consists of
864 all processes in the root CPU cgroup that were not
865 otherwise implicitly placed into a new autogroup.
866 .IP *
867 If autogrouping is disabled, then the root task group consists of
868 all processes in the root CPU cgroup.
869 .IP *
870 If group scheduling was disabled (i.e., the kernel was configured without
871 .BR CONFIG_FAIR_GROUP_SCHED ),
872 then all of the processes on the system are notionally placed
873 in a single task group.
875 Under group scheduling,
876 a thread's nice value has an effect for scheduling decisions
877 .IR "only relative to other threads in the same task group" .
878 This has some surprising consequences in terms of the traditional semantics
879 of the nice value on UNIX systems.
880 In particular, if autogrouping
881 is enabled (which is the default in various distributions), then employing
882 .BR setpriority (2)
884 .BR nice (1)
885 on a process has an effect only for scheduling relative
886 to other processes executed in the same session
887 (typically: the same terminal window).
889 Conversely, for two processes that are (for example)
890 the sole CPU-bound processes in different sessions
891 (e.g., different terminal windows,
892 each of whose jobs are tied to different autogroups),
893 .IR "modifying the nice value of the process in one of the sessions"
894 .IR "has no effect"
895 in terms of the scheduler's decisions relative to the
896 process in the other session.
897 .\" More succinctly: the nice(1) command is in many cases a no-op since
898 .\" Linux 2.6.38.
900 A possibly useful workaround here is to use a command such as
901 the following to modify the autogroup nice value for
902 .I all
903 of the processes in a terminal session:
905 .in +4n
907 $ \fBecho 10 > /proc/self/autogroup\fP
910 .SS Real-time features in the mainline Linux kernel
911 .\" FIXME . Probably this text will need some minor tweaking
912 .\" ask Carsten Emde about this.
913 Since kernel version 2.6.18, Linux is gradually
914 becoming equipped with real-time capabilities,
915 most of which are derived from the former
916 .I realtime\-preempt
917 patch set.
918 Until the patches have been completely merged into the
919 mainline kernel,
920 they must be installed to achieve the best real-time performance.
921 These patches are named:
923 .in +4n
925 patch\-\fIkernelversion\fP\-rt\fIpatchversion\fP
929 and can be downloaded from
930 .UR http://www.kernel.org\:/pub\:/linux\:/kernel\:/projects\:/rt/
931 .UE .
933 Without the patches and prior to their full inclusion into the mainline
934 kernel, the kernel configuration offers only the three preemption classes
935 .BR CONFIG_PREEMPT_NONE ,
936 .BR CONFIG_PREEMPT_VOLUNTARY ,
938 .B CONFIG_PREEMPT_DESKTOP
939 which respectively provide no, some, and considerable
940 reduction of the worst-case scheduling latency.
942 With the patches applied or after their full inclusion into the mainline
943 kernel, the additional configuration item
944 .B CONFIG_PREEMPT_RT
945 becomes available.
946 If this is selected, Linux is transformed into a regular
947 real-time operating system.
948 The FIFO and RR scheduling policies are then used to run a thread
949 with true real-time priority and a minimum worst-case scheduling latency.
950 .SH NOTES
952 .BR cgroups (7)
953 CPU controller can be used to limit the CPU consumption of
954 groups of processes.
956 Originally, Standard Linux was intended as a general-purpose operating
957 system being able to handle background processes, interactive
958 applications, and less demanding real-time applications (applications that
959 need to usually meet timing deadlines).
960 Although the Linux kernel 2.6
961 allowed for kernel preemption and the newly introduced O(1) scheduler
962 ensures that the time needed to schedule is fixed and deterministic
963 irrespective of the number of active tasks, true real-time computing
964 was not possible up to kernel version 2.6.17.
965 .SH SEE ALSO
966 .ad l
968 .BR chcpu (1),
969 .BR chrt (1),
970 .BR lscpu (1),
971 .BR ps (1),
972 .BR taskset (1),
973 .BR top (1),
974 .BR getpriority (2),
975 .BR mlock (2),
976 .BR mlockall (2),
977 .BR munlock (2),
978 .BR munlockall (2),
979 .BR nice (2),
980 .BR sched_get_priority_max (2),
981 .BR sched_get_priority_min (2),
982 .BR sched_getaffinity (2),
983 .BR sched_getparam (2),
984 .BR sched_getscheduler (2),
985 .BR sched_rr_get_interval (2),
986 .BR sched_setaffinity (2),
987 .BR sched_setparam (2),
988 .BR sched_setscheduler (2),
989 .BR sched_yield (2),
990 .BR setpriority (2),
991 .BR pthread_getaffinity_np (3),
992 .BR pthread_getschedparam (3),
993 .BR pthread_setaffinity_np (3),
994 .BR sched_getcpu (3),
995 .BR capabilities (7),
996 .BR cpuset (7)
999 .I Programming for the real world \- POSIX.4
1000 by Bill O.\& Gallmeister, O'Reilly & Associates, Inc., ISBN 1-56592-074-0.
1002 The Linux kernel source files
1003 .IR Documentation/scheduler/sched\-deadline.txt ,
1004 .IR Documentation/scheduler/sched\-rt\-group.txt ,
1005 .IR Documentation/scheduler/sched\-design\-CFS.txt ,
1007 .IR Documentation/scheduler/sched\-nice\-design.txt