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 an 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
398 (see below) processes.
399 The nice value can be modified using
403 .BR sched_setattr (2).
405 According to POSIX.1, the nice value is a per-process attribute;
406 that is, the threads in a process should share a nice value.
407 However, on Linux, the nice value is a per-thread attribute:
408 different threads in the same process may have different nice values.
410 The range of the nice value
411 varies across UNIX systems.
412 On modern Linux, the range is \-20 (high priority) to +19 (low priority).
413 On some other systems, the range is \-20..20.
414 Very early Linux kernels (Before Linux 2.0) had the range \-infinity..15.
415 .\" Linux before 1.3.36 had \-infinity..15.
416 .\" Since kernel 1.3.43, Linux has the range \-20..19.
418 The degree to which the nice value affects the relative scheduling of
420 processes likewise varies across UNIX systems and
421 across Linux kernel versions.
423 With the advent of the CFS scheduler in kernel 2.6.23,
424 Linux adopted an algorithm that causes
425 relative differences in nice values to have a much stronger effect.
426 In the current implementation, each unit of difference in the
427 nice values of two processes results in a factor of 1.25
428 in the degree to which the scheduler favors the higher priority process.
429 This causes very low nice values (+19) to truly provide little CPU
430 to a process whenever there is any other
431 higher priority load on the system,
432 and makes high nice values (\-20) deliver most of the CPU to applications
433 that require it (e.g., some audio applications).
437 resource limit can be used to define a limit to which
438 an unprivileged process's nice value can be raised; see
442 For further details on the nice value, see the subsections on
443 the autogroup feature and group scheduling, below.
445 .SS SCHED_BATCH: Scheduling batch processes
446 (Since Linux 2.6.16.)
447 \fBSCHED_BATCH\fP can be used only at static priority 0.
448 This policy is similar to \fBSCHED_OTHER\fP in that it schedules
449 the thread according to its dynamic priority
450 (based on the nice value).
451 The difference is that this policy
452 will cause the scheduler to always assume
453 that the thread is CPU-intensive.
454 Consequently, the scheduler will apply a small scheduling
455 penalty with respect to wakeup behavior,
456 so that this thread is mildly disfavored in scheduling decisions.
458 .\" The following paragraph is drawn largely from the text that
459 .\" accompanied Ingo Molnar's patch for the implementation of
461 .\" commit b0a9499c3dd50d333e2aedb7e894873c58da3785
462 This policy is useful for workloads that are noninteractive,
463 but do not want to lower their nice value,
464 and for workloads that want a deterministic scheduling policy without
465 interactivity causing extra preemptions (between the workload's tasks).
467 .SS SCHED_IDLE: Scheduling very low priority jobs
468 (Since Linux 2.6.23.)
469 \fBSCHED_IDLE\fP can be used only at static priority 0;
470 the process nice value has no influence for this policy.
472 This policy is intended for running jobs at extremely low
473 priority (lower even than a +19 nice value with the
479 .SS Resetting scheduling policy for child processes
480 Each thread has a reset-on-fork scheduling flag.
481 When this flag is set, children created by
483 do not inherit privileged scheduling policies.
484 The reset-on-fork flag can be set by either:
487 .B SCHED_RESET_ON_FORK
490 argument when calling
491 .BR sched_setscheduler (2)
492 (since Linux 2.6.32);
496 .B SCHED_FLAG_RESET_ON_FORK
500 .BR sched_setattr (2).
502 Note that the constants used with these two APIs have different names.
503 The state of the reset-on-fork flag can analogously be retrieved using
504 .BR sched_getscheduler (2)
506 .BR sched_getattr (2).
508 The reset-on-fork feature is intended for media-playback applications,
509 and can be used to prevent applications evading the
513 by creating multiple child processes.
515 More precisely, if the reset-on-fork flag is set,
516 the following rules apply for subsequently created children:
518 If the calling thread has a scheduling policy of
522 the policy is reset to
526 If the calling process has a negative nice value,
527 the nice value is reset to zero in child processes.
529 After the reset-on-fork flag has been enabled,
530 it can be reset only if the thread has the
533 This flag is disabled in child processes created by
536 .SS Privileges and resource limits
537 In Linux kernels before 2.6.12, only privileged
539 threads can set a nonzero static priority (i.e., set a real-time
541 The only change that an unprivileged thread can make is to set the
543 policy, and this can be done only if the effective user ID of the caller
544 matches the real or effective user ID of the target thread
545 (i.e., the thread specified by
547 whose policy is being changed.
549 A thread must be privileged
551 in order to set or modify a
555 Since Linux 2.6.12, the
557 resource limit defines a ceiling on an unprivileged thread's
558 static priority for the
563 The rules for changing scheduling policy and priority are as follows:
565 If an unprivileged thread has a nonzero
567 soft limit, then it can change its scheduling policy and priority,
568 subject to the restriction that the priority cannot be set to a
569 value higher than the maximum of its current priority and its
575 soft limit is 0, then the only permitted changes are to lower the priority,
576 or to switch to a non-real-time policy.
578 Subject to the same rules,
579 another unprivileged thread can also make these changes,
580 as long as the effective user ID of the thread making the change
581 matches the real or effective user ID of the target thread.
583 Special rules apply for the
586 In Linux kernels before 2.6.39,
587 an unprivileged thread operating under this policy cannot
588 change its policy, regardless of the value of its
591 In Linux kernels since 2.6.39,
592 .\" commit c02aa73b1d18e43cfd79c2f193b225e84ca497c8
593 an unprivileged thread can switch to either the
597 policy so long as its nice value falls within the range permitted by its
606 limit; as with older kernels,
607 they can make arbitrary changes to scheduling policy and priority.
610 for further information on
612 .SS Limiting the CPU usage of real-time and deadline processes
613 A nonblocking infinite loop in a thread scheduled under the
618 policy can potentially block all other threads from accessing
620 Prior to Linux 2.6.25, the only way of preventing a runaway real-time
621 process from freezing the system was to run (at the console)
622 a shell scheduled under a higher static priority than the tested application.
623 This allows an emergency kill of tested
624 real-time applications that do not block or terminate as expected.
626 Since Linux 2.6.25, there are other techniques for dealing with runaway
627 real-time and deadline processes.
628 One of these is to use the
630 resource limit to set a ceiling on the CPU time that
631 a real-time process may consume.
636 Since version 2.6.25, Linux also provides two
638 files that can be used to reserve a certain amount of CPU time
639 to be used by non-real-time processes.
640 Reserving CPU time in this fashion allows some CPU time to be
641 allocated to (say) a root shell that can be used to kill a runaway process.
642 Both of these files specify time values in microseconds:
644 .IR /proc/sys/kernel/sched_rt_period_us
645 This file specifies a scheduling period that is equivalent to
647 The value in this file can range from 1 to
649 giving an operating range of 1 microsecond to around 35 minutes.
650 The default value in this file is 1,000,000 (1 second).
652 .IR /proc/sys/kernel/sched_rt_runtime_us
653 The value in this file specifies how much of the "period" time
654 can be used by all real-time and deadline scheduled processes
656 The value in this file can range from \-1 to
658 Specifying \-1 makes the runtime the same as the period;
659 that is, no CPU time is set aside for non-real-time processes
660 (which was the Linux behavior before kernel 2.6.25).
661 The default value in this file is 950,000 (0.95 seconds),
662 meaning that 5% of the CPU time is reserved for processes that
663 don't run under a real-time or deadline scheduling policy.
666 A blocked high priority thread waiting for I/O has a certain
667 response time before it is scheduled again.
668 The device driver writer
669 can greatly reduce this response time by using a "slow interrupt"
672 .\" .BR request_irq (9).
674 Child processes inherit the scheduling policy and parameters across a
676 The scheduling policy and parameters are preserved across
679 Memory locking is usually needed for real-time processes to avoid
680 paging delays; this can be done with
685 .SS The autogroup feature
686 .\" commit 5091faa449ee0b7d73bc296a93bca9540fc51d0a
688 the kernel provides a feature known as autogrouping to improve interactive
689 desktop performance in the face of multiprocess, CPU-intensive
690 workloads such as building the Linux kernel with large numbers of
691 parallel build processes (i.e., the
696 This feature operates in conjunction with the
697 CFS scheduler and requires a kernel that is configured with
698 .BR CONFIG_SCHED_AUTOGROUP .
699 On a running system, this feature is enabled or disabled via the file
700 .IR /proc/sys/kernel/sched_autogroup_enabled ;
701 a value of 0 disables the feature, while a value of 1 enables it.
702 The default value in this file is 1, unless the kernel was booted with the
706 A new autogroup is created created when a new session is created via
708 this happens, for example, when a new terminal window is started.
709 A new process created by
711 inherits its parent's autogroup membership.
712 Thus, all of the processes in a session are members of the same autogroup.
713 An autogroup is automatically destroyed when the last process
714 in the group terminates.
716 When autogrouping is enabled, all of the members of an autogroup
717 are placed in the same kernel scheduler "task group".
718 The CFS scheduler employs an algorithm that equalizes the
719 distribution of CPU cycles across task groups.
720 The benefits of this for interactive desktop performance
721 can be described via the following example.
723 Suppose that there are two autogroups competing for the same CPU
724 (i.e., presume either a single CPU system or the use of
726 to confine all the processes to the same CPU on an SMP system).
727 The first group contains ten CPU-bound processes from
728 a kernel build started with
730 The other contains a single CPU-bound process: a video player.
731 The effect of autogrouping is that the two groups will
732 each receive half of the CPU cycles.
733 That is, the video player will receive 50% of the CPU cycles,
734 rather than just 9% of the cycles,
735 which would likely lead to degraded video playback.
736 The situation on an SMP system is more complex,
737 .\" Mike Galbraith, 25 Nov 2016:
738 .\" I'd say something more wishy-washy here, like cycles are
739 .\" distributed fairly across groups and leave it at that, as your
740 .\" detailed example is incorrect due to SMP fairness (which I don't
741 .\" like much because [very unlikely] worst case scenario
742 .\" renders a box sized group incapable of utilizing more that
743 .\" a single CPU total). For example, if a group of NR_CPUS
744 .\" size competes with a singleton, load balancing will try to give
745 .\" the singleton a full CPU of its very own. If groups intersect for
746 .\" whatever reason on say my quad lappy, distribution is 80/20 in
747 .\" favor of the singleton.
748 but the general effect is the same:
749 the scheduler distributes CPU cycles across task groups such that
750 an autogroup that contains a large number of CPU-bound processes
751 does not end up hogging CPU cycles at the expense of the other
754 A process's autogroup (task group) membership can be viewed via the file
755 .IR /proc/[pid]/autogroup :
759 $ \fBcat /proc/1/autogroup\fP
764 This file can also be used to modify the CPU bandwidth allocated
766 This is done by writing a number in the "nice" range to the file
767 to set the autogroup's nice value.
768 The allowed range is from +19 (low priority) to \-20 (high priority).
769 (Writing values outside of this range causes
771 to fail with the error
774 .\" Because of a bug introduced in Linux 4.7
775 .\" (commit 2159197d66770ec01f75c93fb11dc66df81fd45b made changes
776 .\" that exposed the fact that autogroup didn't call scale_load()),
777 .\" it happened that *all* values in this range caused a task group
778 .\" to be further disfavored by the scheduler, with \-20 resulting
779 .\" in the scheduler mildly disfavoring the task group and +19 greatly
782 .\" A patch was posted on 23 Nov 2016
783 .\" ("sched/autogroup: Fix 64bit kernel nice adjustment";
784 .\" check later to see in which kernel version it lands.
786 The autogroup nice setting has the same meaning as the process nice value,
787 but applies to distribution of CPU cycles to the autogroup as a whole,
788 based on the relative nice values of other autogroups.
789 For a process inside an autogroup, the CPU cycles that it receives
790 will be a product of the autogroup's nice value
791 (compared to other autogroups)
792 and the process's nice value
793 (compared to other processes in the same autogroup.
797 CPU controller to place processes in cgroups other than the
798 root CPU cgroup overrides the effect of autogrouping.
800 The autogroup feature groups only processes scheduled under
801 non-real-time policies
806 It does not group processes scheduled under real-time and
808 Those processes are scheduled according to the rules described earlier.
810 .SS The nice value and group scheduling
811 When scheduling non-real-time processes (i.e., those scheduled under the
816 policies), the CFS scheduler employs a technique known as "group scheduling",
817 if the kernel was configured with the
818 .BR CONFIG_FAIR_GROUP_SCHED
819 option (which is typical).
821 Under group scheduling, threads are scheduled in "task groups".
822 Task groups have a hierarchical relationship,
823 rooted under the initial task group on the system,
824 known as the "root task group".
825 Task groups are formed in the following circumstances:
827 All of the threads in a CPU cgroup form a task group.
828 The parent of this task group is the task group of the
829 corresponding parent cgroup.
831 If autogrouping is enabled,
832 then all of the threads that are (implicitly) placed in an autogroup
833 (i.e., the same session, as created by
836 Each new autogroup is thus a separate task group.
837 The root task group is the parent of all such autogroups.
839 If autogrouping is enabled, then the root task group consists of
840 all processes in the root CPU cgroup that were not
841 otherwise implicitly placed into a new autogroup.
843 If autogrouping is disabled, then the root task group consists of
844 all processes in the root CPU cgroup.
846 If group scheduling was disabled (i.e., the kernel was configured without
847 .BR CONFIG_FAIR_GROUP_SCHED ),
848 then all of the processes on the system are notionally placed
849 in a single task group.
851 Under group scheduling,
852 a thread's nice value has an effect for scheduling decisions
853 .IR "only relative to other threads in the same task group" .
854 This has some surprising consequences in terms of the traditional semantics
855 of the nice value on UNIX systems.
856 In particular, if autogrouping
857 is enabled (which is the default), then employing
861 on a process has an effect only for scheduling relative
862 to other processes executed in the same session
863 (typically: the same terminal window).
865 Conversely, for two processes that are (for example)
866 the sole CPU-bound processes in different sessions
867 (e.g., different terminal windows,
868 each of whose jobs are tied to different autogroups),
869 .IR "modifying the nice value of the process in one of the sessions"
871 in terms of the scheduler's decisions relative to the
872 process in the other session.
873 .\" More succinctly: the nice(1) command is in many cases a no-op since
876 .SS Real-time features in the mainline Linux kernel
877 .\" FIXME . Probably this text will need some minor tweaking
878 .\" ask Carsten Emde about this.
879 Since kernel version 2.6.18, Linux is gradually
880 becoming equipped with real-time capabilities,
881 most of which are derived from the former
884 Until the patches have been completely merged into the
886 they must be installed to achieve the best real-time performance.
887 These patches are named:
891 patch-\fIkernelversion\fP-rt\fIpatchversion\fP
895 and can be downloaded from
896 .UR http://www.kernel.org\:/pub\:/linux\:/kernel\:/projects\:/rt/
899 Without the patches and prior to their full inclusion into the mainline
900 kernel, the kernel configuration offers only the three preemption classes
901 .BR CONFIG_PREEMPT_NONE ,
902 .BR CONFIG_PREEMPT_VOLUNTARY ,
904 .B CONFIG_PREEMPT_DESKTOP
905 which respectively provide no, some, and considerable
906 reduction of the worst-case scheduling latency.
908 With the patches applied or after their full inclusion into the mainline
909 kernel, the additional configuration item
912 If this is selected, Linux is transformed into a regular
913 real-time operating system.
914 The FIFO and RR scheduling policies are then used to run a thread
915 with true real-time priority and a minimum worst-case scheduling latency.
919 CPU controller can be used to limit the CPU consumption of
922 Originally, Standard Linux was intended as a general-purpose operating
923 system being able to handle background processes, interactive
924 applications, and less demanding real-time applications (applications that
925 need to usually meet timing deadlines).
926 Although the Linux kernel 2.6
927 allowed for kernel preemption and the newly introduced O(1) scheduler
928 ensures that the time needed to schedule is fixed and deterministic
929 irrespective of the number of active tasks, true real-time computing
930 was not possible up to kernel version 2.6.17.
942 .BR sched_get_priority_max (2),
943 .BR sched_get_priority_min (2),
944 .BR sched_getaffinity (2),
945 .BR sched_getparam (2),
946 .BR sched_getscheduler (2),
947 .BR sched_rr_get_interval (2),
948 .BR sched_setaffinity (2),
949 .BR sched_setparam (2),
950 .BR sched_setscheduler (2),
953 .BR pthread_getaffinity_np (3),
954 .BR pthread_setaffinity_np (3),
955 .BR sched_getcpu (3),
956 .BR capabilities (7),
960 .I Programming for the real world \- POSIX.4
961 by Bill O. Gallmeister, O'Reilly & Associates, Inc., ISBN 1-56592-074-0.
963 The Linux kernel source files
964 .IR Documentation/scheduler/sched-deadline.txt ,
965 .IR Documentation/scheduler/sched-rt-group.txt ,
966 .IR Documentation/scheduler/sched-design-CFS.txt ,
968 .IR Documentation/scheduler/sched-nice-design.txt