diff options
| author | Alejandro Colomar <alx.manpages@gmail.com> | 2022-03-18 20:25:09 +0100 |
|---|---|---|
| committer | Alejandro Colomar <alx.manpages@gmail.com> | 2022-03-20 02:36:25 +0100 |
| commit | 1ae6b2c7b818e5d8804cf8d3abfdb6fba32119db (patch) | |
| tree | ed237286398c7c8d9eb4f763b171895f84a38c11 /man7/sched.7 | |
| parent | 3d58eb6da4c3468ca8184b1d8317c6ae7d080d7a (diff) | |
| download | man-pages-1ae6b2c7b818e5d8804cf8d3abfdb6fba32119db.tar.gz | |
Many pages: Fix style issues reported by `make lint-groff`
Plus some other found in the process.
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
Diffstat (limited to 'man7/sched.7')
| -rw-r--r-- | man7/sched.7 | 78 |
1 files changed, 41 insertions, 37 deletions
diff --git a/man7/sched.7 b/man7/sched.7 index 0723f75ebf..e6937ac112 100644 --- a/man7/sched.7 +++ b/man7/sched.7 @@ -234,13 +234,13 @@ before which it should finish execution, and a which is the CPU time necessary for executing the job. The moment when a task wakes up because a new job has to be executed is called the -.IR "arrival time" +.I arrival time (also referred to as the request time or release time). The -.IR "start time" +.I start time is the time at which a task starts its execution. The -.I "absolute deadline" +.I absolute deadline is thus obtained by adding the relative deadline to the arrival time. .PP The following diagram clarifies these terms: @@ -272,7 +272,7 @@ usual practice is to set Runtime to something bigger than the average computation time (or worst-case execution time for hard real-time tasks), Deadline to the relative deadline, and Period to the period of the task. Thus, for -.BR SCHED_DEADLINE +.B SCHED_DEADLINE scheduling, we have: .PP .in +4n @@ -292,7 +292,7 @@ The three deadline-scheduling parameters correspond to the .IR sched_runtime , .IR sched_deadline , and -.IR sched_period +.I sched_period fields of the .I sched_attr structure; see @@ -302,13 +302,17 @@ These fields express values in nanoseconds. .\" "make sched_period the same as sched_deadline". .\" This needs to be documented. If -.IR sched_period +.I sched_period is specified as 0, then it is made the same as .IR sched_deadline . .PP The kernel requires that: .PP - sched_runtime <= sched_deadline <= sched_period +.in +4n +.EX +sched_runtime <= sched_deadline <= sched_period +.EE +.in .PP .\" See __checkparam_dl in kernel/sched/core.c In addition, under the current implementation, @@ -344,12 +348,12 @@ Runtime divided by its Period. .PP In order to fulfill the guarantees that are made when a thread is admitted to the -.BR SCHED_DEADLINE +.B SCHED_DEADLINE policy, -.BR SCHED_DEADLINE +.B SCHED_DEADLINE threads are the highest priority (user controllable) threads in the system; if any -.BR SCHED_DEADLINE +.B SCHED_DEADLINE thread is runnable, it will preempt any thread scheduled under one of the other policies. .PP @@ -398,9 +402,9 @@ The nice value is an attribute that can be used to influence the CPU scheduler to favor or disfavor a process in scheduling decisions. It affects the scheduling of -.BR SCHED_OTHER +.B SCHED_OTHER and -.BR SCHED_BATCH +.B SCHED_BATCH (see below) processes. The nice value can be modified using .BR nice (2), @@ -422,7 +426,7 @@ Very early Linux kernels (Before Linux 2.0) had the range \-infinity..15. .\" Since kernel 1.3.43, Linux has the range \-20..19. .PP The degree to which the nice value affects the relative scheduling of -.BR SCHED_OTHER +.B SCHED_OTHER processes likewise varies across UNIX systems and across Linux kernel versions. .PP @@ -439,7 +443,7 @@ and makes high nice values (\-20) deliver most of the CPU to applications that require it (e.g., some audio applications). .PP On Linux, the -.BR RLIMIT_NICE +.B RLIMIT_NICE resource limit can be used to define a limit to which an unprivileged process's nice value can be raised; see .BR setrlimit (2) @@ -501,7 +505,7 @@ or specifying the .B SCHED_FLAG_RESET_ON_FORK flag in -.IR attr.sched_flags +.I attr.sched_flags when calling .BR sched_setattr (2). .PP @@ -513,7 +517,7 @@ and .PP The reset-on-fork feature is intended for media-playback applications, and can be used to prevent applications evading the -.BR RLIMIT_RTTIME +.B RLIMIT_RTTIME resource limit (see .BR getrlimit (2)) by creating multiple child processes. @@ -526,7 +530,7 @@ If the calling thread has a scheduling policy of or .BR SCHED_RR , the policy is reset to -.BR SCHED_OTHER +.B SCHED_OTHER in child processes. .IP * If the calling process has a negative nice value, @@ -534,7 +538,7 @@ the nice value is reset to zero in child processes. .PP After the reset-on-fork flag has been enabled, it can be reset only if the thread has the -.BR CAP_SYS_NICE +.B CAP_SYS_NICE capability. This flag is disabled in child processes created by .BR fork (2). @@ -555,7 +559,7 @@ whose policy is being changed. A thread must be privileged .RB ( CAP_SYS_NICE ) in order to set or modify a -.BR SCHED_DEADLINE +.B SCHED_DEADLINE policy. .PP Since Linux 2.6.12, the @@ -587,21 +591,21 @@ as long as the effective user ID of the thread making the change matches the real or effective user ID of the target thread. .IP * Special rules apply for the -.BR SCHED_IDLE +.B SCHED_IDLE policy. In Linux kernels before 2.6.39, an unprivileged thread operating under this policy cannot change its policy, regardless of the value of its -.BR RLIMIT_RTPRIO +.B RLIMIT_RTPRIO resource limit. In Linux kernels since 2.6.39, .\" commit c02aa73b1d18e43cfd79c2f193b225e84ca497c8 an unprivileged thread can switch to either the -.BR SCHED_BATCH +.B SCHED_BATCH or the -.BR SCHED_OTHER +.B SCHED_OTHER policy so long as its nice value falls within the range permitted by its -.BR RLIMIT_NICE +.B RLIMIT_NICE resource limit (see .BR getrlimit (2)). .PP @@ -620,7 +624,7 @@ A nonblocking infinite loop in a thread scheduled under the .BR SCHED_FIFO , .BR SCHED_RR , or -.BR SCHED_DEADLINE +.B SCHED_DEADLINE policy can potentially block all other threads from accessing the CPU forever. Prior to Linux 2.6.25, the only way of preventing a runaway real-time @@ -632,7 +636,7 @@ real-time applications that do not block or terminate as expected. Since Linux 2.6.25, there are other techniques for dealing with runaway real-time and deadline processes. One of these is to use the -.BR RLIMIT_RTTIME +.B RLIMIT_RTTIME resource limit to set a ceiling on the CPU time that a real-time process may consume. See @@ -647,7 +651,7 @@ Reserving CPU time in this fashion allows some CPU time to be allocated to (say) a root shell that can be used to kill a runaway process. Both of these files specify time values in microseconds: .TP -.IR /proc/sys/kernel/sched_rt_period_us +.I /proc/sys/kernel/sched_rt_period_us This file specifies a scheduling period that is equivalent to 100% CPU bandwidth. The value in this file can range from 1 to @@ -655,7 +659,7 @@ The value in this file can range from 1 to giving an operating range of 1 microsecond to around 35 minutes. The default value in this file is 1,000,000 (1 second). .TP -.IR /proc/sys/kernel/sched_rt_runtime_us +.I /proc/sys/kernel/sched_rt_runtime_us The value in this file specifies how much of the "period" time can be used by all real-time and deadline scheduled processes on the system. @@ -695,7 +699,7 @@ desktop performance in the face of multiprocess, CPU-intensive workloads such as building the Linux kernel with large numbers of parallel build processes (i.e., the .BR make (1) -.BR \-j +.B \-j flag). .PP This feature operates in conjunction with the @@ -705,7 +709,7 @@ On a running system, this feature is enabled or disabled via the file .IR /proc/sys/kernel/sched_autogroup_enabled ; a value of 0 disables the feature, while a value of 1 enables it. The default value in this file is 1, unless the kernel was booted with the -.IR noautogroup +.I noautogroup parameter. .PP A new autogroup is created when a new session is created via @@ -731,7 +735,7 @@ Suppose that there are two autogroups competing for the same CPU to confine all the processes to the same CPU on an SMP system). The first group contains ten CPU-bound processes from a kernel build started with -.IR "make\ \-j10" . +.IR "make\~\-j10" . The other contains a single CPU-bound process: a video player. The effect of autogrouping is that the two groups will each receive half of the CPU cycles. @@ -757,7 +761,7 @@ does not end up hogging CPU cycles at the expense of the other jobs on the system. .PP A process's autogroup (task group) membership can be viewed via the file -.IR /proc/[pid]/autogroup : +.IR /proc/ pid /autogroup : .PP .in +4n .EX @@ -817,10 +821,10 @@ When scheduling non-real-time processes (i.e., those scheduled under the .BR SCHED_OTHER , .BR SCHED_BATCH , and -.BR SCHED_IDLE +.B SCHED_IDLE policies), the CFS scheduler employs a technique known as "group scheduling", if the kernel was configured with the -.BR CONFIG_FAIR_GROUP_SCHED +.B CONFIG_FAIR_GROUP_SCHED option (which is typical). .PP Under group scheduling, threads are scheduled in "task groups". @@ -871,8 +875,8 @@ Conversely, for two processes that are (for example) the sole CPU-bound processes in different sessions (e.g., different terminal windows, each of whose jobs are tied to different autogroups), -.IR "modifying the nice value of the process in one of the sessions" -.IR "has no effect" +.I modifying the nice value of the process in one of the sessions +.I has no effect in terms of the scheduler's decisions relative to the process in the other session. .\" More succinctly: the nice(1) command is in many cases a no-op since @@ -985,4 +989,4 @@ The Linux kernel source files .IR Documentation/scheduler/sched\-rt\-group.txt , .IR Documentation/scheduler/sched\-design\-CFS.txt , and -.IR Documentation/scheduler/sched\-nice\-design.txt +.I Documentation/scheduler/sched\-nice\-design.txt |