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>
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.
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.
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.
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/>.
30 .\" Worth looking at: http://rt.wiki.kernel.org/index.php
32 .TH SCHED 7 2016-10-08 "Linux" "Linux Programmer's Manual"
34 sched \- overview of CPU scheduling
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.
41 Linux provides the following system calls for controlling
42 the CPU scheduling behavior, policy, and priority of processes
43 (or, more precisely, threads).
46 Set a new nice value for the calling thread,
47 and return the new nice value.
50 Return the nice value of a thread, a process group,
51 or the set of threads owned by a specified user.
54 Set the nice value of a thread, a process group,
55 or the set of threads owned by a specified user.
57 .BR sched_setscheduler (2)
58 Set the scheduling policy and parameters of a specified thread.
60 .BR sched_getscheduler (2)
61 Return the scheduling policy of a specified thread.
63 .BR sched_setparam (2)
64 Set the scheduling parameters of a specified thread.
66 .BR sched_getparam (2)
67 Fetch the scheduling parameters of a specified thread.
69 .BR sched_get_priority_max (2)
70 Return the maximum priority available in a specified scheduling policy.
72 .BR sched_get_priority_min (2)
73 Return the minimum priority available in a specified scheduling policy.
75 .BR sched_rr_get_interval (2)
76 Fetch the quantum used for threads that are scheduled under
77 the "round-robin" scheduling policy.
80 Cause the caller to relinquish the CPU,
81 so that some other thread be executed.
83 .BR sched_setaffinity (2)
85 Set the CPU affinity of a specified thread.
87 .BR sched_getaffinity (2)
89 Get the CPU affinity of a specified thread.
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)
96 .BR sched_setparam (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
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
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 threads 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:
160 A \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
165 When a \fBSCHED_FIFO\fP thread becomes runnable, it
166 will be inserted at the end of the list for its priority.
169 .BR sched_setscheduler (2),
170 .BR sched_setparam (2),
172 .BR sched_setattr (2)
174 \fBSCHED_FIFO\fP (or \fBSCHED_RR\fP) thread identified by
175 \fIpid\fP at the start of the list if it was runnable.
176 As a consequence, it may preempt the currently running thread if
177 it has the same priority.
178 (POSIX.1 specifies that the thread should go to the end
180 .\" In 2.2.x and 2.4.x, the thread is placed at the front of the queue
181 .\" In 2.0.x, the Right Thing happened: the thread went to the back -- MTK
185 will be put at the end of the list.
187 No other events will move a thread
188 scheduled under the \fBSCHED_FIFO\fP policy in the wait list of
189 runnable threads with equal static priority.
192 thread runs until either it is blocked by an I/O request, it is
193 preempted by a higher priority thread, or it calls
195 .SS SCHED_RR: Round-robin scheduling
196 \fBSCHED_RR\fP is a simple enhancement of \fBSCHED_FIFO\fP.
198 described above for \fBSCHED_FIFO\fP also applies to \fBSCHED_RR\fP,
199 except that each thread is allowed to run only for a maximum time
201 If a \fBSCHED_RR\fP thread has been running for a time
202 period equal to or longer than the time quantum, it will be put at the
203 end of the list for its priority.
204 A \fBSCHED_RR\fP thread that has
205 been preempted by a higher priority thread and subsequently resumes
206 execution as a running thread will complete the unexpired portion of
207 its round-robin time quantum.
208 The length of the time quantum can be
210 .BR sched_rr_get_interval (2).
211 .\" On Linux 2.4, the length of the RR interval is influenced
212 .\" by the process nice value -- MTK
214 .SS SCHED_DEADLINE: Sporadic task model deadline scheduling
215 Since version 3.14, Linux provides a deadline scheduling policy
216 .RB ( SCHED_DEADLINE ).
217 This policy is currently implemented using
218 GEDF (Global Earliest Deadline First)
219 in conjunction with CBS (Constant Bandwidth Server).
220 To set and fetch this policy and associated attributes,
221 one must use the Linux-specific
222 .BR sched_setattr (2)
224 .BR sched_getattr (2)
227 A sporadic task is one that has a sequence of jobs, where each
228 job is activated at most once per period.
230 .IR "relative deadline" ,
231 before which it should finish execution, and a
232 .IR "computation time" ,
233 which is the CPU time necessary for executing the job.
234 The moment when a task wakes up
235 because a new job has to be executed is called the
237 (also referred to as the request time or release time).
240 is the time at which a task starts its execution.
242 .I "absolute deadline"
243 is thus obtained by adding the relative deadline to the arrival time.
245 The following diagram clarifies these terms:
249 arrival/wakeup absolute deadline
253 -----x--------xooooooooooooooooo--------x--------x---
255 |<------- relative deadline ------>|
256 |<-------------- period ------------------->|
262 policy for a thread using
263 .BR sched_setattr (2),
264 one can specify three parameters:
269 These parameters do not necessarily correspond to the aforementioned terms:
270 usual practice is to set Runtime to something bigger than the average
271 computation time (or worst-case execution time for hard real-time tasks),
272 Deadline to the relative deadline, and Period to the period of the task.
279 arrival/wakeup absolute deadline
283 -----x--------xooooooooooooooooo--------x--------x---
284 |<-- Runtime ------->|
285 |<----------- Deadline ----------->|
286 |<-------------- Period ------------------->|
290 The three deadline-scheduling parameters correspond to the
298 .BR sched_setattr (2).
299 These fields express values in nanoseconds.
300 .\" FIXME It looks as though specifying sched_period as 0 means
301 .\" "make sched_period the same as sched_deadline".
302 .\" This needs to be documented.
305 is specified as 0, then it is made the same as
308 The kernel requires that:
310 sched_runtime <= sched_deadline <= sched_period
312 .\" See __checkparam_dl in kernel/sched/core.c
313 In addition, under the current implementation,
314 all of the parameter values must be at least 1024
315 (i.e., just over one microsecond,
316 which is the resolution of the implementation), and less than 2^63.
317 If any of these checks fails,
318 .BR sched_setattr (2)
322 The CBS guarantees non-interference between tasks, by throttling
323 threads that attempt to over-run their specified Runtime.
325 To ensure deadline scheduling guarantees,
326 the kernel must prevent situations where the set of
328 threads is not feasible (schedulable) within the given constraints.
329 The kernel thus performs an admittance test when setting or changing
331 policy and attributes.
332 This admission test calculates whether the change is feasible;
334 .BR sched_setattr (2)
338 For example, it is required (but not necessarily sufficient) for
339 the total utilization to be less than or equal to the total number of
340 CPUs available, where, since each thread can maximally run for
341 Runtime per Period, that thread's utilization is its
342 Runtime divided by its Period.
344 In order to fulfill the guarantees that are made when
345 a thread is admitted to the
349 threads are the highest priority (user controllable) threads in the
353 it will preempt any thread scheduled under one of the other policies.
357 by a thread scheduled under the
359 policy will fail with the error
361 unless the thread has its reset-on-fork flag set (see below).
367 will yield the current job and wait for a new period to begin.
369 .\" FIXME Calling sched_getparam() on a SCHED_DEADLINE thread
370 .\" fails with EINVAL, but sched_getscheduler() succeeds.
371 .\" Is that intended? (Why?)
373 .SS SCHED_OTHER: Default Linux time-sharing scheduling
374 \fBSCHED_OTHER\fP can be used at only static priority 0
375 (i.e., threads under real-time policies always have priority over
378 \fBSCHED_OTHER\fP is the standard Linux time-sharing scheduler that is
379 intended for all threads that do not require the special
380 real-time mechanisms.
382 The thread to run is chosen from the static
383 priority 0 list based on a \fIdynamic\fP priority that is determined only
385 The dynamic priority is based on the nice value (see below)
386 and is increased for each time quantum the thread is ready to run,
387 but denied to run by the scheduler.
388 This ensures fair progress among all \fBSCHED_OTHER\fP threads.
391 The nice value is a per-process attribute
392 that can be used to influence the CPU scheduler to
393 favor or disfavor a process in scheduling decisions.
394 It affects the scheduling of
400 According to POSIX.1, the threads in a process should share a nice value.
401 However, on Linux, the nice value is a per-thread attribute:
402 different threads in the same process may have different nice values.
403 The nice value can be modified using
407 .BR sched_setattr (2).
409 The range of the nice value
410 varies across UNIX systems.
411 On modern Linux, the range is \-20 (high priority) to +19 (low priority).
412 On some other systems, the range is \-20..20.
413 Very early Linux kernels (Before Linux 2.0) had the range \-infinity..15.
414 .\" Linux before 1.3.36 had \-infinity..15.
415 .\" Since kernel 1.3.43, Linux has the range \-20..19.
417 The degree to which the nice value affects the relative scheduling of
419 processes likewise varies across UNIX systems and
420 across Linux kernel versions.
422 With the advent of the CFS scheduler in kernel 2.6.23,
423 Linux adopted an algorithm that causes
424 relative differences in nice values to have a much stronger effect.
425 In the current implementation, each unit of difference in the
426 nice values of two processes results in a factor of 1.25
427 in the degree to which the scheduler favors the higher priority process.
428 This causes very low nice values (+19) to truly provide little CPU
429 to a process whenever there is any other
430 higher priority load on the system,
431 and makes high nice values (\-20) deliver most of the CPU to applications
432 that require it (e.g., some audio applications).
436 resource limit can be used to define a limit to which
437 an unprivileged process's nice value can be raised; see
441 .SS SCHED_BATCH: Scheduling batch processes
442 (Since Linux 2.6.16.)
443 \fBSCHED_BATCH\fP can be used only at static priority 0.
444 This policy is similar to \fBSCHED_OTHER\fP in that it schedules
445 the thread according to its dynamic priority
446 (based on the nice value).
447 The difference is that this policy
448 will cause the scheduler to always assume
449 that the thread is CPU-intensive.
450 Consequently, the scheduler will apply a small scheduling
451 penalty with respect to wakeup behavior,
452 so that this thread is mildly disfavored in scheduling decisions.
454 .\" The following paragraph is drawn largely from the text that
455 .\" accompanied Ingo Molnar's patch for the implementation of
457 .\" commit b0a9499c3dd50d333e2aedb7e894873c58da3785
458 This policy is useful for workloads that are noninteractive,
459 but do not want to lower their nice value,
460 and for workloads that want a deterministic scheduling policy without
461 interactivity causing extra preemptions (between the workload's tasks).
463 .SS SCHED_IDLE: Scheduling very low priority jobs
464 (Since Linux 2.6.23.)
465 \fBSCHED_IDLE\fP can be used only at static priority 0;
466 the process nice value has no influence for this policy.
468 This policy is intended for running jobs at extremely low
469 priority (lower even than a +19 nice value with the
475 .SS Resetting scheduling policy for child processes
476 Each thread has a reset-on-fork scheduling flag.
477 When this flag is set, children created by
479 do not inherit privileged scheduling policies.
480 The reset-on-fork flag can be set by either:
483 .B SCHED_RESET_ON_FORK
486 argument when calling
487 .BR sched_setscheduler (2)
488 (since Linux 2.6.32);
492 .B SCHED_FLAG_RESET_ON_FORK
496 .BR sched_setattr (2).
498 Note that the constants used with these two APIs have different names.
499 The state of the reset-on-fork flag can analogously be retrieved using
500 .BR sched_getscheduler (2)
502 .BR sched_getattr (2).
504 The reset-on-fork feature is intended for media-playback applications,
505 and can be used to prevent applications evading the
509 by creating multiple child processes.
511 More precisely, if the reset-on-fork flag is set,
512 the following rules apply for subsequently created children:
514 If the calling thread has a scheduling policy of
518 the policy is reset to
522 If the calling process has a negative nice value,
523 the nice value is reset to zero in child processes.
525 After the reset-on-fork flag has been enabled,
526 it can be reset only if the thread has the
529 This flag is disabled in child processes created by
532 .SS Privileges and resource limits
533 In Linux kernels before 2.6.12, only privileged
535 threads can set a nonzero static priority (i.e., set a real-time
537 The only change that an unprivileged thread can make is to set the
539 policy, and this can be done only if the effective user ID of the caller
540 matches the real or effective user ID of the target thread
541 (i.e., the thread specified by
543 whose policy is being changed.
545 A thread must be privileged
547 in order to set or modify a
551 Since Linux 2.6.12, the
553 resource limit defines a ceiling on an unprivileged thread's
554 static priority for the
559 The rules for changing scheduling policy and priority are as follows:
561 If an unprivileged thread has a nonzero
563 soft limit, then it can change its scheduling policy and priority,
564 subject to the restriction that the priority cannot be set to a
565 value higher than the maximum of its current priority and its
571 soft limit is 0, then the only permitted changes are to lower the priority,
572 or to switch to a non-real-time policy.
574 Subject to the same rules,
575 another unprivileged thread can also make these changes,
576 as long as the effective user ID of the thread making the change
577 matches the real or effective user ID of the target thread.
579 Special rules apply for the
582 In Linux kernels before 2.6.39,
583 an unprivileged thread operating under this policy cannot
584 change its policy, regardless of the value of its
587 In Linux kernels since 2.6.39,
588 .\" commit c02aa73b1d18e43cfd79c2f193b225e84ca497c8
589 an unprivileged thread can switch to either the
593 policy so long as its nice value falls within the range permitted by its
602 limit; as with older kernels,
603 they can make arbitrary changes to scheduling policy and priority.
606 for further information on
608 .SS Limiting the CPU usage of real-time and deadline processes
609 A nonblocking infinite loop in a thread scheduled under the
614 policy can potentially block all other threads from accessing
616 Prior to Linux 2.6.25, the only way of preventing a runaway real-time
617 process from freezing the system was to run (at the console)
618 a shell scheduled under a higher static priority than the tested application.
619 This allows an emergency kill of tested
620 real-time applications that do not block or terminate as expected.
622 Since Linux 2.6.25, there are other techniques for dealing with runaway
623 real-time and deadline processes.
624 One of these is to use the
626 resource limit to set a ceiling on the CPU time that
627 a real-time process may consume.
632 Since version 2.6.25, Linux also provides two
634 files that can be used to reserve a certain amount of CPU time
635 to be used by non-real-time processes.
636 Reserving CPU time in this fashion allows some CPU time to be
637 allocated to (say) a root shell that can be used to kill a runaway process.
638 Both of these files specify time values in microseconds:
640 .IR /proc/sys/kernel/sched_rt_period_us
641 This file specifies a scheduling period that is equivalent to
643 The value in this file can range from 1 to
645 giving an operating range of 1 microsecond to around 35 minutes.
646 The default value in this file is 1,000,000 (1 second).
648 .IR /proc/sys/kernel/sched_rt_runtime_us
649 The value in this file specifies how much of the "period" time
650 can be used by all real-time and deadline scheduled processes
652 The value in this file can range from \-1 to
654 Specifying \-1 makes the runtime the same as the period;
655 that is, no CPU time is set aside for non-real-time processes
656 (which was the Linux behavior before kernel 2.6.25).
657 The default value in this file is 950,000 (0.95 seconds),
658 meaning that 5% of the CPU time is reserved for processes that
659 don't run under a real-time or deadline scheduling policy.
662 A blocked high priority thread waiting for I/O has a certain
663 response time before it is scheduled again.
664 The device driver writer
665 can greatly reduce this response time by using a "slow interrupt"
668 .\" .BR request_irq (9).
670 Child processes inherit the scheduling policy and parameters across a
672 The scheduling policy and parameters are preserved across
675 Memory locking is usually needed for real-time processes to avoid
676 paging delays; this can be done with
683 CPU controller can be used to limit the CPU consumption of
686 Originally, Standard Linux was intended as a general-purpose operating
687 system being able to handle background processes, interactive
688 applications, and less demanding real-time applications (applications that
689 need to usually meet timing deadlines).
690 Although the Linux kernel 2.6
691 allowed for kernel preemption and the newly introduced O(1) scheduler
692 ensures that the time needed to schedule is fixed and deterministic
693 irrespective of the number of active tasks, true real-time computing
694 was not possible up to kernel version 2.6.17.
695 .SS Real-time features in the mainline Linux kernel
696 .\" FIXME . Probably this text will need some minor tweaking
697 .\" ask Carsten Emde about this.
698 From kernel version 2.6.18 onward, however, Linux is gradually
699 becoming equipped with real-time capabilities,
700 most of which are derived from the former
703 Until the patches have been completely merged into the
705 they must be installed to achieve the best real-time performance.
706 These patches are named:
710 patch-\fIkernelversion\fP-rt\fIpatchversion\fP
714 and can be downloaded from
715 .UR http://www.kernel.org\:/pub\:/linux\:/kernel\:/projects\:/rt/
718 Without the patches and prior to their full inclusion into the mainline
719 kernel, the kernel configuration offers only the three preemption classes
720 .BR CONFIG_PREEMPT_NONE ,
721 .BR CONFIG_PREEMPT_VOLUNTARY ,
723 .B CONFIG_PREEMPT_DESKTOP
724 which respectively provide no, some, and considerable
725 reduction of the worst-case scheduling latency.
727 With the patches applied or after their full inclusion into the mainline
728 kernel, the additional configuration item
731 If this is selected, Linux is transformed into a regular
732 real-time operating system.
733 The FIFO and RR scheduling policies are then used to run a thread
734 with true real-time priority and a minimum worst-case scheduling latency.
746 .BR sched_get_priority_max (2),
747 .BR sched_get_priority_min (2),
748 .BR sched_getaffinity (2),
749 .BR sched_getparam (2),
750 .BR sched_getscheduler (2),
751 .BR sched_rr_get_interval (2),
752 .BR sched_setaffinity (2),
753 .BR sched_setparam (2),
754 .BR sched_setscheduler (2),
757 .BR pthread_getaffinity_np (3),
758 .BR pthread_setaffinity_np (3),
759 .BR sched_getcpu (3),
760 .BR capabilities (7),
764 .I Programming for the real world \- POSIX.4
765 by Bill O. Gallmeister, O'Reilly & Associates, Inc., ISBN 1-56592-074-0.
767 The Linux kernel source files
768 .IR Documentation/scheduler/sched-deadline.txt ,
769 .IR Documentation/scheduler/sched-rt-group.txt ,
770 .IR Documentation/scheduler/sched-design-CFS.txt ,
772 .IR Documentation/scheduler/sched-nice-design.txt