{ "content": [ { "type": "text", "text": "# sched(7) (man)\n\n**Summary:** sched - overview of CPU scheduling\n\n## See Also\n\n- chcpu(1)\n- chrt(1)\n- lscpu(1)\n- ps(1)\n- taskset(1)\n- top(1)\n- getpriority(2)\n- mlock(2)\n- mlockall(2)\n- munlock(2)\n- munlockall(2)\n- nice(2)\n- schedgetprioritymax(2)\n- schedgetprioritymin(2)\n- schedgetaffinity(2)\n- schedgetparam(2)\n- schedgetscheduler(2)\n- schedrrgetinterval(2)\n- schedsetaffinity(2)\n- schedsetparam(2)\n- schedsetscheduler(2)\n- schedyield(2)\n- setpriority(2)\n- pthreadgetaffinitynp(3)\n- pthreadgetschedparam(3)\n- pthreadsetaffinitynp(3)\n- schedgetcpu(3)\n- capabilities(7)\n- cpuset(7)\n\n## Section Outline\n\n- **NAME** (2 lines)\n- **DESCRIPTION** (3 lines) — 11 subsections\n - API summary (55 lines)\n - Scheduling policies (170 lines)\n - The nice value (49 lines)\n - Resetting scheduling policy for child processes (30 lines)\n - Privileges and resource limits (35 lines)\n - Limiting the CPU usage of real-time and deadline processes (31 lines)\n - Response time (4 lines)\n - Miscellaneous (6 lines)\n - The autogroup feature (58 lines)\n - The nice value and group scheduling (43 lines)\n - Real-time features in the mainline Linux kernel (20 lines)\n- **NOTES** (10 lines)\n- **SEE ALSO** (14 lines)\n- **COLOPHON** (7 lines)\n\n## Full Content\n\n### NAME\n\nsched - overview of CPU scheduling\n\n### DESCRIPTION\n\nSince Linux 2.6.23, the default scheduler is CFS, the \"Completely Fair Scheduler\". The CFS\nscheduler replaced the earlier \"O(1)\" scheduler.\n\n#### API summary\n\nLinux provides the following system calls for controlling the CPU scheduling behavior, pol‐\nicy, and priority of processes (or, more precisely, threads).\n\nnice(2)\nSet a new nice value for the calling thread, and return the new nice value.\n\ngetpriority(2)\nReturn the nice value of a thread, a process group, or the set of threads owned by a\nspecified user.\n\nsetpriority(2)\nSet the nice value of a thread, a process group, or the set of threads owned by a\nspecified user.\n\nschedsetscheduler(2)\nSet the scheduling policy and parameters of a specified thread.\n\nschedgetscheduler(2)\nReturn the scheduling policy of a specified thread.\n\nschedsetparam(2)\nSet the scheduling parameters of a specified thread.\n\nschedgetparam(2)\nFetch the scheduling parameters of a specified thread.\n\nschedgetprioritymax(2)\nReturn the maximum priority available in a specified scheduling policy.\n\nschedgetprioritymin(2)\nReturn the minimum priority available in a specified scheduling policy.\n\nschedrrgetinterval(2)\nFetch the quantum used for threads that are scheduled under the \"round-robin\" schedul‐\ning policy.\n\nschedyield(2)\nCause the caller to relinquish the CPU, so that some other thread be executed.\n\nschedsetaffinity(2)\n(Linux-specific) Set the CPU affinity of a specified thread.\n\nschedgetaffinity(2)\n(Linux-specific) Get the CPU affinity of a specified thread.\n\nschedsetattr(2)\nSet the scheduling policy and parameters of a specified thread. This (Linux-specific)\nsystem call provides a superset of the functionality of schedsetscheduler(2) and\nschedsetparam(2).\n\nschedgetattr(2)\nFetch the scheduling policy and parameters of a specified thread. This (Linux-spe‐\ncific) system call provides a superset of the functionality of schedgetscheduler(2)\nand schedgetparam(2).\n\n#### Scheduling policies\n\nThe scheduler is the kernel component that decides which runnable thread will be executed by\nthe CPU next. Each thread has an associated scheduling policy and a static scheduling prior‐\nity, schedpriority. The scheduler makes its decisions based on knowledge of the scheduling\npolicy and static priority of all threads on the system.\n\nFor threads scheduled under one of the normal scheduling policies (SCHEDOTHER, SCHEDIDLE,\nSCHEDBATCH), schedpriority is not used in scheduling decisions (it must be specified as 0).\n\nProcesses scheduled under one of the real-time policies (SCHEDFIFO, SCHEDRR) have a\nschedpriority value in the range 1 (low) to 99 (high). (As the numbers imply, real-time\nthreads always have higher priority than normal threads.) Note well: POSIX.1 requires an im‐\nplementation to support only a minimum 32 distinct priority levels for the real-time poli‐\ncies, and some systems supply just this minimum. Portable programs should use schedgetpri‐‐\noritymin(2) and schedgetprioritymax(2) to find the range of priorities supported for a\nparticular policy.\n\nConceptually, the scheduler maintains a list of runnable threads for each possible schedpri‐\nority value. In order to determine which thread runs next, the scheduler looks for the\nnonempty list with the highest static priority and selects the thread at the head of this\nlist.\n\nA thread's scheduling policy determines where it will be inserted into the list of threads\nwith equal static priority and how it will move inside this list.\n\nAll scheduling is preemptive: if a thread with a higher static priority becomes ready to run,\nthe currently running thread will be preempted and returned to the wait list for its static\npriority level. The scheduling policy determines the ordering only within the list of\nrunnable threads with equal static priority.\n\nSCHEDFIFO: First in-first out scheduling\nSCHEDFIFO can be used only with static priorities higher than 0, which means that when a\nSCHEDFIFO thread becomes runnable, it will always immediately preempt any currently running\nSCHEDOTHER, SCHEDBATCH, or SCHEDIDLE thread. SCHEDFIFO is a simple scheduling algorithm\nwithout time slicing. For threads scheduled under the SCHEDFIFO policy, the following rules\napply:\n\n1) A running SCHEDFIFO thread that has been preempted by another thread of higher priority\nwill stay at the head of the list for its priority and will resume execution as soon as\nall threads of higher priority are blocked again.\n\n2) When a blocked SCHEDFIFO thread becomes runnable, it will be inserted at the end of the\nlist for its priority.\n\n3) If a call to schedsetscheduler(2), schedsetparam(2), schedsetattr(2), pthreadsetsched‐‐\nparam(3), or pthreadsetschedprio(3) changes the priority of the running or runnable\nSCHEDFIFO thread identified by pid the effect on the thread's position in the list de‐\npends on the direction of the change to threads priority:\n\n• If the thread's priority is raised, it is placed at the end of the list for its new\npriority. As a consequence, it may preempt a currently running thread with the same\npriority.\n\n• If the thread's priority is unchanged, its position in the run list is unchanged.\n\n• If the thread's priority is lowered, it is placed at the front of the list for its new\npriority.\n\nAccording to POSIX.1-2008, changes to a thread's priority (or policy) using any mechanism\nother than pthreadsetschedprio(3) should result in the thread being placed at the end of\nthe list for its priority.\n\n4) A thread calling schedyield(2) will be put at the end of the list.\n\nNo other events will move a thread scheduled under the SCHEDFIFO policy in the wait list of\nrunnable threads with equal static priority.\n\nA SCHEDFIFO thread runs until either it is blocked by an I/O request, it is preempted by a\nhigher priority thread, or it calls schedyield(2).\n\nSCHEDRR: Round-robin scheduling\nSCHEDRR is a simple enhancement of SCHEDFIFO. Everything described above for SCHEDFIFO\nalso applies to SCHEDRR, except that each thread is allowed to run only for a maximum time\nquantum. If a SCHEDRR thread has been running for a time period equal to or longer than the\ntime quantum, it will be put at the end of the list for its priority. A SCHEDRR thread that\nhas been preempted by a higher priority thread and subsequently resumes execution as a run‐\nning thread will complete the unexpired portion of its round-robin time quantum. The length\nof the time quantum can be retrieved using schedrrgetinterval(2).\n\nSCHEDDEADLINE: Sporadic task model deadline scheduling\nSince version 3.14, Linux provides a deadline scheduling policy (SCHEDDEADLINE). This pol‐\nicy is currently implemented using GEDF (Global Earliest Deadline First) in conjunction with\nCBS (Constant Bandwidth Server). To set and fetch this policy and associated attributes, one\nmust use the Linux-specific schedsetattr(2) and schedgetattr(2) system calls.\n\nA sporadic task is one that has a sequence of jobs, where each job is activated at most once\nper period. Each job also has a relative deadline, before which it should finish execution,\nand a computation time, which is the CPU time necessary for executing the job. The moment\nwhen a task wakes up because a new job has to be executed is called the arrival time (also\nreferred to as the request time or release time). The start time is the time at which a task\nstarts its execution. The absolute deadline is thus obtained by adding the relative deadline\nto the arrival time.\n\nThe following diagram clarifies these terms:\n\narrival/wakeup absolute deadline\n| start time |\n| | |\nv v v\n-----x--------xooooooooooooooooo--------x--------x---\n|<- comp. time ->|\n|<------- relative deadline ------>|\n|<-------------- period ------------------->|\n\nWhen setting a SCHEDDEADLINE policy for a thread using schedsetattr(2), one can specify\nthree parameters: Runtime, Deadline, and Period. These parameters do not necessarily corre‐\nspond to the aforementioned terms: usual practice is to set Runtime to something bigger than\nthe average computation time (or worst-case execution time for hard real-time tasks), Dead‐\nline to the relative deadline, and Period to the period of the task. Thus, for SCHEDDEAD‐‐\nLINE scheduling, we have:\n\narrival/wakeup absolute deadline\n| start time |\n| | |\nv v v\n-----x--------xooooooooooooooooo--------x--------x---\n|<-- Runtime ------->|\n|<----------- Deadline ----------->|\n|<-------------- Period ------------------->|\n\nThe three deadline-scheduling parameters correspond to the schedruntime, scheddeadline, and\nschedperiod fields of the schedattr structure; see schedsetattr(2). These fields express\nvalues in nanoseconds. If schedperiod is specified as 0, then it is made the same as\nscheddeadline.\n\nThe kernel requires that:\n\nschedruntime <= scheddeadline <= schedperiod\n\nIn addition, under the current implementation, all of the parameter values must be at least\n1024 (i.e., just over one microsecond, which is the resolution of the implementation), and\nless than 2^63. If any of these checks fails, schedsetattr(2) fails with the error EINVAL.\n\nThe CBS guarantees non-interference between tasks, by throttling threads that attempt to\nover-run their specified Runtime.\n\nTo ensure deadline scheduling guarantees, the kernel must prevent situations where the set of\nSCHEDDEADLINE threads is not feasible (schedulable) within the given constraints. The ker‐\nnel thus performs an admittance test when setting or changing SCHEDDEADLINE policy and at‐\ntributes. This admission test calculates whether the change is feasible; if it is not,\nschedsetattr(2) fails with the error EBUSY.\n\nFor example, it is required (but not necessarily sufficient) for the total utilization to be\nless than or equal to the total number of CPUs available, where, since each thread can maxi‐\nmally run for Runtime per Period, that thread's utilization is its Runtime divided by its Pe‐\nriod.\n\nIn order to fulfill the guarantees that are made when a thread is admitted to the SCHEDDEAD‐‐\nLINE policy, SCHEDDEADLINE threads are the highest priority (user controllable) threads in\nthe system; if any SCHEDDEADLINE thread is runnable, it will preempt any thread scheduled\nunder one of the other policies.\n\nA call to fork(2) by a thread scheduled under the SCHEDDEADLINE policy fails with the error\nEAGAIN, unless the thread has its reset-on-fork flag set (see below).\n\nA SCHEDDEADLINE thread that calls schedyield(2) will yield the current job and wait for a\nnew period to begin.\n\nSCHEDOTHER: Default Linux time-sharing scheduling\nSCHEDOTHER can be used at only static priority 0 (i.e., threads under real-time policies al‐\nways have priority over SCHEDOTHER processes). SCHEDOTHER is the standard Linux time-shar‐\ning scheduler that is intended for all threads that do not require the special real-time\nmechanisms.\n\nThe thread to run is chosen from the static priority 0 list based on a dynamic priority that\nis determined only inside this list. The dynamic priority is based on the nice value (see\nbelow) and is increased for each time quantum the thread is ready to run, but denied to run\nby the scheduler. This ensures fair progress among all SCHEDOTHER threads.\n\nIn the Linux kernel source code, the SCHEDOTHER policy is actually named SCHEDNORMAL.\n\n#### The nice value\n\nThe nice value is an attribute that can be used to influence the CPU scheduler to favor or\ndisfavor a process in scheduling decisions. It affects the scheduling of SCHEDOTHER and\nSCHEDBATCH (see below) processes. The nice value can be modified using nice(2), setprior‐‐\nity(2), or schedsetattr(2).\n\nAccording to POSIX.1, the nice value is a per-process attribute; that is, the threads in a\nprocess should share a nice value. However, on Linux, the nice value is a per-thread attri‐\nbute: different threads in the same process may have different nice values.\n\nThe range of the nice value varies across UNIX systems. On modern Linux, the range is -20\n(high priority) to +19 (low priority). On some other systems, the range is -20..20. Very\nearly Linux kernels (Before Linux 2.0) had the range -infinity..15.\n\nThe degree to which the nice value affects the relative scheduling of SCHEDOTHER processes\nlikewise varies across UNIX systems and across Linux kernel versions.\n\nWith the advent of the CFS scheduler in kernel 2.6.23, Linux adopted an algorithm that causes\nrelative differences in nice values to have a much stronger effect. In the current implemen‐\ntation, each unit of difference in the nice values of two processes results in a factor of\n1.25 in the degree to which the scheduler favors the higher priority process. This causes\nvery low nice values (+19) to truly provide little CPU to a process whenever there is any\nother higher priority load on the system, and makes high nice values (-20) deliver most of\nthe CPU to applications that require it (e.g., some audio applications).\n\nOn Linux, the RLIMITNICE resource limit can be used to define a limit to which an unprivi‐\nleged process's nice value can be raised; see setrlimit(2) for details.\n\nFor further details on the nice value, see the subsections on the autogroup feature and group\nscheduling, below.\n\nSCHEDBATCH: Scheduling batch processes\n(Since Linux 2.6.16.) SCHEDBATCH can be used only at static priority 0. This policy is\nsimilar to SCHEDOTHER in that it schedules the thread according to its dynamic priority\n(based on the nice value). The difference is that this policy will cause the scheduler to\nalways assume that the thread is CPU-intensive. Consequently, the scheduler will apply a\nsmall scheduling penalty with respect to wakeup behavior, so that this thread is mildly dis‐\nfavored in scheduling decisions.\n\nThis policy is useful for workloads that are noninteractive, but do not want to lower their\nnice value, and for workloads that want a deterministic scheduling policy without interactiv‐\nity causing extra preemptions (between the workload's tasks).\n\nSCHEDIDLE: Scheduling very low priority jobs\n(Since Linux 2.6.23.) SCHEDIDLE can be used only at static priority 0; the process nice\nvalue has no influence for this policy.\n\nThis policy is intended for running jobs at extremely low priority (lower even than a +19\nnice value with the SCHEDOTHER or SCHEDBATCH policies).\n\n#### Resetting scheduling policy for child processes\n\nEach thread has a reset-on-fork scheduling flag. When this flag is set, children created by\nfork(2) do not inherit privileged scheduling policies. The reset-on-fork flag can be set by\neither:\n\n* ORing the SCHEDRESETONFORK flag into the policy argument when calling schedsetsched‐‐\nuler(2) (since Linux 2.6.32); or\n\n* specifying the SCHEDFLAGRESETONFORK flag in attr.schedflags when calling schedse‐‐\ntattr(2).\n\nNote that the constants used with these two APIs have different names. The state of the re‐\nset-on-fork flag can analogously be retrieved using schedgetscheduler(2) and\nschedgetattr(2).\n\nThe reset-on-fork feature is intended for media-playback applications, and can be used to\nprevent applications evading the RLIMITRTTIME resource limit (see getrlimit(2)) by creating\nmultiple child processes.\n\nMore precisely, if the reset-on-fork flag is set, the following rules apply for subsequently\ncreated children:\n\n* If the calling thread has a scheduling policy of SCHEDFIFO or SCHEDRR, the policy is re‐\nset to SCHEDOTHER in child processes.\n\n* If the calling process has a negative nice value, the nice value is reset to zero in child\nprocesses.\n\nAfter the reset-on-fork flag has been enabled, it can be reset only if the thread has the\nCAPSYSNICE capability. This flag is disabled in child processes created by fork(2).\n\n#### Privileges and resource limits\n\nIn Linux kernels before 2.6.12, only privileged (CAPSYSNICE) threads can set a nonzero\nstatic priority (i.e., set a real-time scheduling policy). The only change that an unprivi‐\nleged thread can make is to set the SCHEDOTHER policy, and this can be done only if the ef‐\nfective user ID of the caller matches the real or effective user ID of the target thread\n(i.e., the thread specified by pid) whose policy is being changed.\n\nA thread must be privileged (CAPSYSNICE) in order to set or modify a SCHEDDEADLINE policy.\n\nSince Linux 2.6.12, the RLIMITRTPRIO resource limit defines a ceiling on an unprivileged\nthread's static priority for the SCHEDRR and SCHEDFIFO policies. The rules for changing\nscheduling policy and priority are as follows:\n\n* If an unprivileged thread has a nonzero RLIMITRTPRIO soft limit, then it can change its\nscheduling policy and priority, subject to the restriction that the priority cannot be set\nto a value higher than the maximum of its current priority and its RLIMITRTPRIO soft\nlimit.\n\n* If the RLIMITRTPRIO soft limit is 0, then the only permitted changes are to lower the\npriority, or to switch to a non-real-time policy.\n\n* Subject to the same rules, another unprivileged thread can also make these changes, as\nlong as the effective user ID of the thread making the change matches the real or effec‐\ntive user ID of the target thread.\n\n* Special rules apply for the SCHEDIDLE policy. In Linux kernels before 2.6.39, an unpriv‐\nileged thread operating under this policy cannot change its policy, regardless of the\nvalue of its RLIMITRTPRIO resource limit. In Linux kernels since 2.6.39, an unprivileged\nthread can switch to either the SCHEDBATCH or the SCHEDOTHER policy so long as its nice\nvalue falls within the range permitted by its RLIMITNICE resource limit (see getr‐‐\nlimit(2)).\n\nPrivileged (CAPSYSNICE) threads ignore the RLIMITRTPRIO limit; as with older kernels, they\ncan make arbitrary changes to scheduling policy and priority. See getrlimit(2) for further\ninformation on RLIMITRTPRIO.\n\n#### Limiting the CPU usage of real-time and deadline processes\n\nA nonblocking infinite loop in a thread scheduled under the SCHEDFIFO, SCHEDRR, or\nSCHEDDEADLINE policy can potentially block all other threads from accessing the CPU forever.\nPrior to Linux 2.6.25, the only way of preventing a runaway real-time process from freezing\nthe system was to run (at the console) a shell scheduled under a higher static priority than\nthe tested application. This allows an emergency kill of tested real-time applications that\ndo not block or terminate as expected.\n\nSince Linux 2.6.25, there are other techniques for dealing with runaway real-time and dead‐\nline processes. One of these is to use the RLIMITRTTIME resource limit to set a ceiling on\nthe CPU time that a real-time process may consume. See getrlimit(2) for details.\n\nSince version 2.6.25, Linux also provides two /proc files that can be used to reserve a cer‐\ntain amount of CPU time to be used by non-real-time processes. Reserving CPU time in this\nfashion allows some CPU time to be allocated to (say) a root shell that can be used to kill a\nrunaway process. Both of these files specify time values in microseconds:\n\n/proc/sys/kernel/schedrtperiodus\nThis file specifies a scheduling period that is equivalent to 100% CPU bandwidth. The\nvalue in this file can range from 1 to INTMAX, giving an operating range of 1 mi‐\ncrosecond to around 35 minutes. The default value in this file is 1,000,000 (1 sec‐\nond).\n\n/proc/sys/kernel/schedrtruntimeus\nThe value in this file specifies how much of the \"period\" time can be used by all\nreal-time and deadline scheduled processes on the system. The value in this file can\nrange from -1 to INTMAX-1. Specifying -1 makes the run time the same as the period;\nthat is, no CPU time is set aside for non-real-time processes (which was the Linux be‐\nhavior before kernel 2.6.25). The default value in this file is 950,000 (0.95 sec‐\nonds), meaning that 5% of the CPU time is reserved for processes that don't run under\na real-time or deadline scheduling policy.\n\n#### Response time\n\nA blocked high priority thread waiting for I/O has a certain response time before it is\nscheduled again. The device driver writer can greatly reduce this response time by using a\n\"slow interrupt\" interrupt handler.\n\n#### Miscellaneous\n\nChild processes inherit the scheduling policy and parameters across a fork(2). The schedul‐\ning policy and parameters are preserved across execve(2).\n\nMemory locking is usually needed for real-time processes to avoid paging delays; this can be\ndone with mlock(2) or mlockall(2).\n\n#### The autogroup feature\n\nSince Linux 2.6.38, the kernel provides a feature known as autogrouping to improve interac‐\ntive desktop performance in the face of multiprocess, CPU-intensive workloads such as build‐\ning the Linux kernel with large numbers of parallel build processes (i.e., the make(1) -j\nflag).\n\nThis feature operates in conjunction with the CFS scheduler and requires a kernel that is\nconfigured with CONFIGSCHEDAUTOGROUP. On a running system, this feature is enabled or dis‐\nabled via the file /proc/sys/kernel/schedautogroupenabled; a value of 0 disables the fea‐\nture, while a value of 1 enables it. The default value in this file is 1, unless the kernel\nwas booted with the noautogroup parameter.\n\nA new autogroup is created when a new session is created via setsid(2); this happens, for ex‐\nample, when a new terminal window is started. A new process created by fork(2) inherits its\nparent's autogroup membership. Thus, all of the processes in a session are members of the\nsame autogroup. An autogroup is automatically destroyed when the last process in the group\nterminates.\n\nWhen autogrouping is enabled, all of the members of an autogroup are placed in the same ker‐\nnel scheduler \"task group\". The CFS scheduler employs an algorithm that equalizes the dis‐\ntribution of CPU cycles across task groups. The benefits of this for interactive desktop\nperformance can be described via the following example.\n\nSuppose that there are two autogroups competing for the same CPU (i.e., presume either a sin‐\ngle CPU system or the use of taskset(1) to confine all the processes to the same CPU on an\nSMP system). The first group contains ten CPU-bound processes from a kernel build started\nwith make -j10. The other contains a single CPU-bound process: a video player. The effect\nof autogrouping is that the two groups will each receive half of the CPU cycles. That is,\nthe video player will receive 50% of the CPU cycles, rather than just 9% of the cycles, which\nwould likely lead to degraded video playback. The situation on an SMP system is more com‐\nplex, but the general effect is the same: the scheduler distributes CPU cycles across task\ngroups such that an autogroup that contains a large number of CPU-bound processes does not\nend up hogging CPU cycles at the expense of the other jobs on the system.\n\nA process's autogroup (task group) membership can be viewed via the file /proc/[pid]/auto‐\ngroup:\n\n$ cat /proc/1/autogroup\n/autogroup-1 nice 0\n\nThis file can also be used to modify the CPU bandwidth allocated to an autogroup. This is\ndone by writing a number in the \"nice\" range to the file to set the autogroup's nice value.\nThe allowed range is from +19 (low priority) to -20 (high priority). (Writing values outside\nof this range causes write(2) to fail with the error EINVAL.)\n\nThe autogroup nice setting has the same meaning as the process nice value, but applies to\ndistribution of CPU cycles to the autogroup as a whole, based on the relative nice values of\nother autogroups. For a process inside an autogroup, the CPU cycles that it receives will be\na product of the autogroup's nice value (compared to other autogroups) and the process's nice\nvalue (compared to other processes in the same autogroup.\n\nThe use of the cgroups(7) CPU controller to place processes in cgroups other than the root\nCPU cgroup overrides the effect of autogrouping.\n\nThe autogroup feature groups only processes scheduled under non-real-time policies\n(SCHEDOTHER, SCHEDBATCH, and SCHEDIDLE). It does not group processes scheduled under\nreal-time and deadline policies. Those processes are scheduled according to the rules de‐\nscribed earlier.\n\n#### The nice value and group scheduling\n\nWhen scheduling non-real-time processes (i.e., those scheduled under the SCHEDOTHER,\nSCHEDBATCH, and SCHEDIDLE policies), the CFS scheduler employs a technique known as \"group\nscheduling\", if the kernel was configured with the CONFIGFAIRGROUPSCHED option (which is\ntypical).\n\nUnder group scheduling, threads are scheduled in \"task groups\". Task groups have a hierar‐\nchical relationship, rooted under the initial task group on the system, known as the \"root\ntask group\". Task groups are formed in the following circumstances:\n\n* All of the threads in a CPU cgroup form a task group. The parent of this task group is\nthe task group of the corresponding parent cgroup.\n\n* If autogrouping is enabled, then all of the threads that are (implicitly) placed in an au‐\ntogroup (i.e., the same session, as created by setsid(2)) form a task group. Each new au‐\ntogroup is thus a separate task group. The root task group is the parent of all such au‐\ntogroups.\n\n* If autogrouping is enabled, then the root task group consists of all processes in the root\nCPU cgroup that were not otherwise implicitly placed into a new autogroup.\n\n* If autogrouping is disabled, then the root task group consists of all processes in the\nroot CPU cgroup.\n\n* If group scheduling was disabled (i.e., the kernel was configured without CON‐‐\nFIGFAIRGROUPSCHED), then all of the processes on the system are notionally placed in a\nsingle task group.\n\nUnder group scheduling, a thread's nice value has an effect for scheduling decisions only\nrelative to other threads in the same task group. This has some surprising consequences in\nterms of the traditional semantics of the nice value on UNIX systems. In particular, if au‐\ntogrouping is enabled (which is the default in various distributions), then employing setpri‐‐\nority(2) or nice(1) on a process has an effect only for scheduling relative to other pro‐\ncesses executed in the same session (typically: the same terminal window).\n\nConversely, for two processes that are (for example) the sole CPU-bound processes in differ‐\nent sessions (e.g., different terminal windows, each of whose jobs are tied to different au‐\ntogroups), modifying the nice value of the process in one of the sessions has no effect in\nterms of the scheduler's decisions relative to the process in the other session. A possibly\nuseful workaround here is to use a command such as the following to modify the autogroup nice\nvalue for all of the processes in a terminal session:\n\n$ echo 10 > /proc/self/autogroup\n\n#### Real-time features in the mainline Linux kernel\n\nSince kernel version 2.6.18, Linux is gradually becoming equipped with real-time capabili‐\nties, most of which are derived from the former realtime-preempt patch set. Until the\npatches have been completely merged into the mainline kernel, they must be installed to\nachieve the best real-time performance. These patches are named:\n\npatch-kernelversion-rtpatchversion\n\nand can be downloaded from ⟨http://www.kernel.org/pub/linux/kernel/projects/rt/⟩.\n\nWithout the patches and prior to their full inclusion into the mainline kernel, the kernel\nconfiguration offers only the three preemption classes CONFIGPREEMPTNONE, CONFIGPRE‐‐\nEMPTVOLUNTARY, and CONFIGPREEMPTDESKTOP which respectively provide no, some, and consider‐\nable reduction of the worst-case scheduling latency.\n\nWith the patches applied or after their full inclusion into the mainline kernel, the addi‐\ntional configuration item CONFIGPREEMPTRT becomes available. If this is selected, Linux is\ntransformed into a regular real-time operating system. The FIFO and RR scheduling policies\nare then used to run a thread with true real-time priority and a minimum worst-case schedul‐\ning latency.\n\n### NOTES\n\nThe cgroups(7) CPU controller can be used to limit the CPU consumption of groups of pro‐\ncesses.\n\nOriginally, Standard Linux was intended as a general-purpose operating system being able to\nhandle background processes, interactive applications, and less demanding real-time applica‐\ntions (applications that need to usually meet timing deadlines). Although the Linux kernel\n2.6 allowed for kernel preemption and the newly introduced O(1) scheduler ensures that the\ntime needed to schedule is fixed and deterministic irrespective of the number of active\ntasks, true real-time computing was not possible up to kernel version 2.6.17.\n\n### SEE ALSO\n\nchcpu(1), chrt(1), lscpu(1), ps(1), taskset(1), top(1), getpriority(2), mlock(2),\nmlockall(2), munlock(2), munlockall(2), nice(2), schedgetprioritymax(2),\nschedgetprioritymin(2), schedgetaffinity(2), schedgetparam(2), schedgetscheduler(2),\nschedrrgetinterval(2), schedsetaffinity(2), schedsetparam(2), schedsetscheduler(2),\nschedyield(2), setpriority(2), pthreadgetaffinitynp(3), pthreadgetschedparam(3),\npthreadsetaffinitynp(3), schedgetcpu(3), capabilities(7), cpuset(7)\n\nProgramming for the real world - POSIX.4 by Bill O. Gallmeister, O'Reilly & Associates, Inc.,\nISBN 1-56592-074-0.\n\nThe Linux kernel source files Documentation/scheduler/sched-deadline.txt,\nDocumentation/scheduler/sched-rt-group.txt, Documentation/scheduler/sched-design-CFS.txt, and\nDocumentation/scheduler/sched-nice-design.txt\n\n### COLOPHON\n\nThis page is part of release 5.10 of the Linux man-pages project. A description of the\nproject, information about reporting bugs, and the latest version of this page, can be found\nat https://www.kernel.org/doc/man-pages/.\n\n\n\nLinux 2019-08-02 SCHED(7)\n\n" } ], "structuredContent": { "command": "sched", "section": "7", "mode": "man", "summary": "sched - overview of CPU scheduling", "synopsis": null, "flags": [], "examples": [], "see_also": [ { "name": "chcpu", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/chcpu/1/json" }, { "name": "chrt", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/chrt/1/json" }, { "name": "lscpu", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/lscpu/1/json" }, { "name": "ps", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/ps/1/json" }, { "name": "taskset", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/taskset/1/json" }, { "name": "top", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/top/1/json" }, { "name": "getpriority", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/getpriority/2/json" }, { "name": "mlock", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/mlock/2/json" }, { "name": "mlockall", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/mlockall/2/json" }, { "name": "munlock", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/munlock/2/json" }, { "name": "munlockall", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/munlockall/2/json" }, { "name": "nice", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/nice/2/json" }, { "name": "schedgetprioritymax", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/schedgetprioritymax/2/json" }, { "name": "schedgetprioritymin", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/schedgetprioritymin/2/json" }, { "name": "schedgetaffinity", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/schedgetaffinity/2/json" }, { "name": "schedgetparam", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/schedgetparam/2/json" }, { "name": "schedgetscheduler", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/schedgetscheduler/2/json" }, { "name": "schedrrgetinterval", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/schedrrgetinterval/2/json" }, { "name": "schedsetaffinity", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/schedsetaffinity/2/json" }, { "name": "schedsetparam", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/schedsetparam/2/json" }, { "name": "schedsetscheduler", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/schedsetscheduler/2/json" }, { "name": "schedyield", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/schedyield/2/json" }, { "name": "setpriority", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/setpriority/2/json" }, { "name": "pthreadgetaffinitynp", "section": "3", "url": "https://www.chedong.com/phpMan.php/man/pthreadgetaffinitynp/3/json" }, { "name": "pthreadgetschedparam", "section": "3", "url": "https://www.chedong.com/phpMan.php/man/pthreadgetschedparam/3/json" }, { "name": "pthreadsetaffinitynp", "section": "3", "url": "https://www.chedong.com/phpMan.php/man/pthreadsetaffinitynp/3/json" }, { "name": "schedgetcpu", "section": "3", "url": "https://www.chedong.com/phpMan.php/man/schedgetcpu/3/json" }, { "name": "capabilities", "section": "7", "url": "https://www.chedong.com/phpMan.php/man/capabilities/7/json" }, { "name": "cpuset", "section": "7", "url": "https://www.chedong.com/phpMan.php/man/cpuset/7/json" } ], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "DESCRIPTION", "lines": 3, "subsections": [ { "name": "API summary", "lines": 55 }, { "name": "Scheduling policies", "lines": 170 }, { "name": "The nice value", "lines": 49 }, { "name": "Resetting scheduling policy for child processes", "lines": 30 }, { "name": "Privileges and resource limits", "lines": 35 }, { "name": "Limiting the CPU usage of real-time and deadline processes", "lines": 31 }, { "name": "Response time", "lines": 4 }, { "name": "Miscellaneous", "lines": 6 }, { "name": "The autogroup feature", "lines": 58 }, { "name": "The nice value and group scheduling", "lines": 43 }, { "name": "Real-time features in the mainline Linux kernel", "lines": 20 } ] }, { "name": "NOTES", "lines": 10, "subsections": [] }, { "name": "SEE ALSO", "lines": 14, "subsections": [] }, { "name": "COLOPHON", "lines": 7, "subsections": [] } ] } }