1 @node Resource Usage And Limitation, Non-Local Exits, Date and Time, Top
2 @c %MENU% Functions for examining resource usage and getting and setting limits
3 @chapter Resource Usage And Limitation
4 This chapter describes functions for examining how much of various kinds of
5 resources (CPU time, memory, etc.) a process has used and getting and setting
6 limits on future usage.
9 * Resource Usage:: Measuring various resources used.
10 * Limits on Resources:: Specifying limits on resource usage.
11 * Priority:: Reading or setting process run priority.
12 * Memory Resources:: Querying memory available resources.
13 * Processor Resources:: Learn about the processors available.
18 @section Resource Usage
20 @pindex sys/resource.h
21 The function @code{getrusage} and the data type @code{struct rusage}
22 are used to examine the resource usage of a process. They are declared
23 in @file{sys/resource.h}.
25 @deftypefun int getrusage (int @var{processes}, struct rusage *@var{rusage})
26 @standards{BSD, sys/resource.h}
27 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
28 @c On HURD, this calls task_info 3 times. On UNIX, it's a syscall.
29 This function reports resource usage totals for processes specified by
30 @var{processes}, storing the information in @code{*@var{rusage}}.
32 In most systems, @var{processes} has only two valid values:
36 @standards{BSD, sys/resource.h}
37 Just the current process.
40 @standards{BSD, sys/resource.h}
41 All child processes (direct and indirect) that have already terminated.
44 The return value of @code{getrusage} is zero for success, and @code{-1}
49 The argument @var{processes} is not valid.
53 One way of getting resource usage for a particular child process is with
54 the function @code{wait4}, which returns totals for a child when it
55 terminates. @xref{BSD Wait Functions}.
57 @deftp {Data Type} {struct rusage}
58 @standards{BSD, sys/resource.h}
59 This data type stores various resource usage statistics. It has the
60 following members, and possibly others:
63 @item struct timeval ru_utime
64 Time spent executing user instructions.
66 @item struct timeval ru_stime
67 Time spent in operating system code on behalf of @var{processes}.
69 @item long int ru_maxrss
70 The maximum resident set size used, in kilobytes. That is, the maximum
71 number of kilobytes of physical memory that @var{processes} used
74 @item long int ru_ixrss
75 An integral value expressed in kilobytes times ticks of execution, which
76 indicates the amount of memory used by text that was shared with other
79 @item long int ru_idrss
80 An integral value expressed the same way, which is the amount of
81 unshared memory used for data.
83 @item long int ru_isrss
84 An integral value expressed the same way, which is the amount of
85 unshared memory used for stack space.
87 @item long int ru_minflt
88 The number of page faults which were serviced without requiring any I/O.
90 @item long int ru_majflt
91 The number of page faults which were serviced by doing I/O.
93 @item long int ru_nswap
94 The number of times @var{processes} was swapped entirely out of main memory.
96 @item long int ru_inblock
97 The number of times the file system had to read from the disk on behalf
100 @item long int ru_oublock
101 The number of times the file system had to write to the disk on behalf
104 @item long int ru_msgsnd
105 Number of IPC messages sent.
107 @item long int ru_msgrcv
108 Number of IPC messages received.
110 @item long int ru_nsignals
111 Number of signals received.
113 @item long int ru_nvcsw
114 The number of times @var{processes} voluntarily invoked a context switch
115 (usually to wait for some service).
117 @item long int ru_nivcsw
118 The number of times an involuntary context switch took place (because
119 a time slice expired, or another process of higher priority was
124 @node Limits on Resources
125 @section Limiting Resource Usage
126 @cindex resource limits
127 @cindex limits on resource usage
130 You can specify limits for the resource usage of a process. When the
131 process tries to exceed a limit, it may get a signal, or the system call
132 by which it tried to do so may fail, depending on the resource. Each
133 process initially inherits its limit values from its parent, but it can
134 subsequently change them.
136 There are two per-process limits associated with a resource:
141 The current limit is the value the system will not allow usage to
142 exceed. It is also called the ``soft limit'' because the process being
143 limited can generally raise the current limit at will.
144 @cindex current limit
148 The maximum limit is the maximum value to which a process is allowed to
149 set its current limit. It is also called the ``hard limit'' because
150 there is no way for a process to get around it. A process may lower
151 its own maximum limit, but only the superuser may increase a maximum
153 @cindex maximum limit
157 @pindex sys/resource.h
158 The symbols for use with @code{getrlimit}, @code{setrlimit},
159 @code{getrlimit64}, and @code{setrlimit64} are defined in
160 @file{sys/resource.h}.
162 @deftypefun int getrlimit (int @var{resource}, struct rlimit *@var{rlp})
163 @standards{BSD, sys/resource.h}
164 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
165 @c Direct syscall on most systems.
166 Read the current and maximum limits for the resource @var{resource}
167 and store them in @code{*@var{rlp}}.
169 The return value is @code{0} on success and @code{-1} on failure. The
170 only possible @code{errno} error condition is @code{EFAULT}.
172 When the sources are compiled with @code{_FILE_OFFSET_BITS == 64} on a
173 32-bit system this function is in fact @code{getrlimit64}. Thus, the
174 LFS interface transparently replaces the old interface.
177 @deftypefun int getrlimit64 (int @var{resource}, struct rlimit64 *@var{rlp})
178 @standards{Unix98, sys/resource.h}
179 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
180 @c Direct syscall on most systems, wrapper to getrlimit otherwise.
181 This function is similar to @code{getrlimit} but its second parameter is
182 a pointer to a variable of type @code{struct rlimit64}, which allows it
183 to read values which wouldn't fit in the member of a @code{struct
186 If the sources are compiled with @code{_FILE_OFFSET_BITS == 64} on a
187 32-bit machine, this function is available under the name
188 @code{getrlimit} and so transparently replaces the old interface.
191 @deftypefun int setrlimit (int @var{resource}, const struct rlimit *@var{rlp})
192 @standards{BSD, sys/resource.h}
193 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
194 @c Direct syscall on most systems; lock-taking critical section on HURD.
195 Change the current and maximum limits of the process for the resource
196 @var{resource} to the values provided in @code{*@var{rlp}}.
198 The return value is @code{0} on success and @code{-1} on failure. The
199 following @code{errno} error condition is possible:
205 The process tried to raise a current limit beyond the maximum limit.
208 The process tried to raise a maximum limit, but is not superuser.
212 When the sources are compiled with @code{_FILE_OFFSET_BITS == 64} on a
213 32-bit system this function is in fact @code{setrlimit64}. Thus, the
214 LFS interface transparently replaces the old interface.
217 @deftypefun int setrlimit64 (int @var{resource}, const struct rlimit64 *@var{rlp})
218 @standards{Unix98, sys/resource.h}
219 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
220 @c Wrapper for setrlimit or direct syscall.
221 This function is similar to @code{setrlimit} but its second parameter is
222 a pointer to a variable of type @code{struct rlimit64} which allows it
223 to set values which wouldn't fit in the member of a @code{struct
226 If the sources are compiled with @code{_FILE_OFFSET_BITS == 64} on a
227 32-bit machine this function is available under the name
228 @code{setrlimit} and so transparently replaces the old interface.
231 @deftp {Data Type} {struct rlimit}
232 @standards{BSD, sys/resource.h}
233 This structure is used with @code{getrlimit} to receive limit values,
234 and with @code{setrlimit} to specify limit values for a particular process
235 and resource. It has two fields:
238 @item rlim_t rlim_cur
241 @item rlim_t rlim_max
245 For @code{getrlimit}, the structure is an output; it receives the current
246 values. For @code{setrlimit}, it specifies the new values.
249 For the LFS functions a similar type is defined in @file{sys/resource.h}.
251 @deftp {Data Type} {struct rlimit64}
252 @standards{Unix98, sys/resource.h}
253 This structure is analogous to the @code{rlimit} structure above, but
254 its components have wider ranges. It has two fields:
257 @item rlim64_t rlim_cur
258 This is analogous to @code{rlimit.rlim_cur}, but with a different type.
260 @item rlim64_t rlim_max
261 This is analogous to @code{rlimit.rlim_max}, but with a different type.
266 Here is a list of resources for which you can specify a limit. Memory
267 and file sizes are measured in bytes.
271 @standards{BSD, sys/resource.h}
272 The maximum amount of CPU time the process can use. If it runs for
273 longer than this, it gets a signal: @code{SIGXCPU}. The value is
274 measured in seconds. @xref{Operation Error Signals}.
277 @standards{BSD, sys/resource.h}
278 The maximum size of file the process can create. Trying to write a
279 larger file causes a signal: @code{SIGXFSZ}. @xref{Operation Error
283 @standards{BSD, sys/resource.h}
284 The maximum size of data memory for the process. If the process tries
285 to allocate data memory beyond this amount, the allocation function
289 @standards{BSD, sys/resource.h}
290 The maximum stack size for the process. If the process tries to extend
291 its stack past this size, it gets a @code{SIGSEGV} signal.
292 @xref{Program Error Signals}.
295 @standards{BSD, sys/resource.h}
296 The maximum size core file that this process can create. If the process
297 terminates and would dump a core file larger than this, then no core
298 file is created. So setting this limit to zero prevents core files from
302 @standards{BSD, sys/resource.h}
303 The maximum amount of physical memory that this process should get.
304 This parameter is a guide for the system's scheduler and memory
305 allocator; the system may give the process more memory when there is a
309 @standards{BSD, sys/resource.h}
310 The maximum amount of memory that can be locked into physical memory (so
311 it will never be paged out).
314 @standards{BSD, sys/resource.h}
315 The maximum number of processes that can be created with the same user ID.
316 If you have reached the limit for your user ID, @code{fork} will fail
317 with @code{EAGAIN}. @xref{Creating a Process}.
321 @standardsx{RLIMIT_NOFILE, BSD, sys/resource.h}
322 The maximum number of files that the process can open. If it tries to
323 open more files than this, its open attempt fails with @code{errno}
324 @code{EMFILE}. @xref{Error Codes}. Not all systems support this limit;
325 GNU does, and 4.4 BSD does.
328 @standards{Unix98, sys/resource.h}
329 The maximum size of total memory that this process should get. If the
330 process tries to allocate more memory beyond this amount with, for
331 example, @code{brk}, @code{malloc}, @code{mmap} or @code{sbrk}, the
332 allocation function fails.
335 @standards{BSD, sys/resource.h}
336 The number of different resource limits. Any valid @var{resource}
337 operand must be less than @code{RLIM_NLIMITS}.
340 @deftypevr Constant rlim_t RLIM_INFINITY
341 @standards{BSD, sys/resource.h}
342 This constant stands for a value of ``infinity'' when supplied as
343 the limit value in @code{setrlimit}.
347 The following are historical functions to do some of what the functions
348 above do. The functions above are better choices.
350 @code{ulimit} and the command symbols are declared in @file{ulimit.h}.
353 @deftypefun {long int} ulimit (int @var{cmd}, @dots{})
354 @standards{BSD, ulimit.h}
355 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
356 @c Wrapper for getrlimit, setrlimit or
357 @c sysconf(_SC_OPEN_MAX)->getdtablesize->getrlimit.
359 @code{ulimit} gets the current limit or sets the current and maximum
360 limit for a particular resource for the calling process according to the
363 If you are getting a limit, the command argument is the only argument.
364 If you are setting a limit, there is a second argument:
365 @code{long int} @var{limit} which is the value to which you are setting
368 The @var{cmd} values and the operations they specify are:
372 Get the current limit on the size of a file, in units of 512 bytes.
375 Set the current and maximum limit on the size of a file to @var{limit} *
380 There are also some other @var{cmd} values that may do things on some
381 systems, but they are not supported.
383 Only the superuser may increase a maximum limit.
385 When you successfully get a limit, the return value of @code{ulimit} is
386 that limit, which is never negative. When you successfully set a limit,
387 the return value is zero. When the function fails, the return value is
388 @code{-1} and @code{errno} is set according to the reason:
392 A process tried to increase a maximum limit, but is not superuser.
398 @code{vlimit} and its resource symbols are declared in @file{sys/vlimit.h}.
401 @deftypefun int vlimit (int @var{resource}, int @var{limit})
402 @standards{BSD, sys/vlimit.h}
403 @safety{@prelim{}@mtunsafe{@mtasurace{:setrlimit}}@asunsafe{}@acsafe{}}
404 @c It calls getrlimit and modifies the rlim_cur field before calling
405 @c setrlimit. There's a window for a concurrent call to setrlimit that
406 @c modifies e.g. rlim_max, which will be lost if running as super-user.
408 @code{vlimit} sets the current limit for a resource for a process.
410 @var{resource} identifies the resource:
414 Maximum CPU time. Same as @code{RLIMIT_CPU} for @code{setrlimit}.
416 Maximum file size. Same as @code{RLIMIT_FSIZE} for @code{setrlimit}.
418 Maximum data memory. Same as @code{RLIMIT_DATA} for @code{setrlimit}.
420 Maximum stack size. Same as @code{RLIMIT_STACK} for @code{setrlimit}.
422 Maximum core file size. Same as @code{RLIMIT_COR} for @code{setrlimit}.
424 Maximum physical memory. Same as @code{RLIMIT_RSS} for @code{setrlimit}.
427 The return value is zero for success, and @code{-1} with @code{errno} set
428 accordingly for failure:
432 The process tried to set its current limit beyond its maximum limit.
438 @section Process CPU Priority And Scheduling
439 @cindex process priority
441 @cindex priority of a process
443 When multiple processes simultaneously require CPU time, the system's
444 scheduling policy and process CPU priorities determine which processes
445 get it. This section describes how that determination is made and
446 @glibcadj{} functions to control it.
448 It is common to refer to CPU scheduling simply as scheduling and a
449 process' CPU priority simply as the process' priority, with the CPU
450 resource being implied. Bear in mind, though, that CPU time is not the
451 only resource a process uses or that processes contend for. In some
452 cases, it is not even particularly important. Giving a process a high
453 ``priority'' may have very little effect on how fast a process runs with
454 respect to other processes. The priorities discussed in this section
455 apply only to CPU time.
457 CPU scheduling is a complex issue and different systems do it in wildly
458 different ways. New ideas continually develop and find their way into
459 the intricacies of the various systems' scheduling algorithms. This
460 section discusses the general concepts, some specifics of systems
461 that commonly use @theglibc{}, and some standards.
463 For simplicity, we talk about CPU contention as if there is only one CPU
464 in the system. But all the same principles apply when a processor has
465 multiple CPUs, and knowing that the number of processes that can run at
466 any one time is equal to the number of CPUs, you can easily extrapolate
469 The functions described in this section are all defined by the POSIX.1
470 and POSIX.1b standards (the @code{sched@dots{}} functions are POSIX.1b).
471 However, POSIX does not define any semantics for the values that these
472 functions get and set. In this chapter, the semantics are based on the
473 Linux kernel's implementation of the POSIX standard. As you will see,
474 the Linux implementation is quite the inverse of what the authors of the
475 POSIX syntax had in mind.
478 * Absolute Priority:: The first tier of priority. Posix
479 * Realtime Scheduling:: Scheduling among the process nobility
480 * Basic Scheduling Functions:: Get/set scheduling policy, priority
481 * Extensible Scheduling:: Parameterized scheduling policies.
482 * Traditional Scheduling:: Scheduling among the vulgar masses
483 * CPU Affinity:: Limiting execution to certain CPUs
488 @node Absolute Priority
489 @subsection Absolute Priority
490 @cindex absolute priority
491 @cindex priority, absolute
493 Every process has an absolute priority, and it is represented by a number.
494 The higher the number, the higher the absolute priority.
496 @cindex realtime CPU scheduling
497 On systems of the past, and most systems today, all processes have
498 absolute priority 0 and this section is irrelevant. In that case,
499 @xref{Traditional Scheduling}. Absolute priorities were invented to
500 accommodate realtime systems, in which it is vital that certain processes
501 be able to respond to external events happening in real time, which
502 means they cannot wait around while some other process that @emph{wants
503 to}, but doesn't @emph{need to} run occupies the CPU.
506 @cindex preemptive scheduling
507 When two processes are in contention to use the CPU at any instant, the
508 one with the higher absolute priority always gets it. This is true even if the
509 process with the lower priority is already using the CPU (i.e., the
510 scheduling is preemptive). Of course, we're only talking about
511 processes that are running or ``ready to run,'' which means they are
512 ready to execute instructions right now. When a process blocks to wait
513 for something like I/O, its absolute priority is irrelevant.
515 @cindex runnable process
516 @strong{NB:} The term ``runnable'' is a synonym for ``ready to run.''
518 When two processes are running or ready to run and both have the same
519 absolute priority, it's more interesting. In that case, who gets the
520 CPU is determined by the scheduling policy. If the processes have
521 absolute priority 0, the traditional scheduling policy described in
522 @ref{Traditional Scheduling} applies. Otherwise, the policies described
523 in @ref{Realtime Scheduling} apply.
525 You normally give an absolute priority above 0 only to a process that
526 can be trusted not to hog the CPU. Such processes are designed to block
527 (or terminate) after relatively short CPU runs.
529 A process begins life with the same absolute priority as its parent
530 process. Functions described in @ref{Basic Scheduling Functions} can
533 Only a privileged process can change a process' absolute priority to
534 something other than @code{0}. Only a privileged process or the
535 target process' owner can change its absolute priority at all.
537 POSIX requires absolute priority values used with the realtime
538 scheduling policies to be consecutive with a range of at least 32. On
539 Linux, they are 1 through 99. The functions
540 @code{sched_get_priority_max} and @code{sched_set_priority_min} portably
541 tell you what the range is on a particular system.
544 @subsubsection Using Absolute Priority
546 One thing you must keep in mind when designing real time applications is
547 that having higher absolute priority than any other process doesn't
548 guarantee the process can run continuously. Two things that can wreck a
549 good CPU run are interrupts and page faults.
551 Interrupt handlers live in that limbo between processes. The CPU is
552 executing instructions, but they aren't part of any process. An
553 interrupt will stop even the highest priority process. So you must
554 allow for slight delays and make sure that no device in the system has
555 an interrupt handler that could cause too long a delay between
556 instructions for your process.
558 Similarly, a page fault causes what looks like a straightforward
559 sequence of instructions to take a long time. The fact that other
560 processes get to run while the page faults in is of no consequence,
561 because as soon as the I/O is complete, the higher priority process will
562 kick them out and run again, but the wait for the I/O itself could be a
563 problem. To neutralize this threat, use @code{mlock} or
566 There are a few ramifications of the absoluteness of this priority on a
567 single-CPU system that you need to keep in mind when you choose to set a
568 priority and also when you're working on a program that runs with high
569 absolute priority. Consider a process that has higher absolute priority
570 than any other process in the system and due to a bug in its program, it
571 gets into an infinite loop. It will never cede the CPU. You can't run
572 a command to kill it because your command would need to get the CPU in
573 order to run. The errant program is in complete control. It controls
574 the vertical, it controls the horizontal.
576 There are two ways to avoid this: 1) keep a shell running somewhere with
577 a higher absolute priority or 2) keep a controlling terminal attached to
578 the high priority process group. All the priority in the world won't
579 stop an interrupt handler from running and delivering a signal to the
580 process if you hit Control-C.
582 Some systems use absolute priority as a means of allocating a fixed
583 percentage of CPU time to a process. To do this, a super high priority
584 privileged process constantly monitors the process' CPU usage and raises
585 its absolute priority when the process isn't getting its entitled share
586 and lowers it when the process is exceeding it.
588 @strong{NB:} The absolute priority is sometimes called the ``static
589 priority.'' We don't use that term in this manual because it misses the
590 most important feature of the absolute priority: its absoluteness.
593 @node Realtime Scheduling
594 @subsection Realtime Scheduling
595 @cindex realtime scheduling
597 Whenever two processes with the same absolute priority are ready to run,
598 the kernel has a decision to make, because only one can run at a time.
599 If the processes have absolute priority 0, the kernel makes this decision
600 as described in @ref{Traditional Scheduling}. Otherwise, the decision
601 is as described in this section.
603 If two processes are ready to run but have different absolute priorities,
604 the decision is much simpler, and is described in @ref{Absolute
607 Each process has a scheduling policy. For processes with absolute
608 priority other than zero, there are two available:
612 First Come First Served
617 The most sensible case is where all the processes with a certain
618 absolute priority have the same scheduling policy. We'll discuss that
621 In Round Robin, processes share the CPU, each one running for a small
622 quantum of time (``time slice'') and then yielding to another in a
623 circular fashion. Of course, only processes that are ready to run and
624 have the same absolute priority are in this circle.
626 In First Come First Served, the process that has been waiting the
627 longest to run gets the CPU, and it keeps it until it voluntarily
628 relinquishes the CPU, runs out of things to do (blocks), or gets
629 preempted by a higher priority process.
631 First Come First Served, along with maximal absolute priority and
632 careful control of interrupts and page faults, is the one to use when a
633 process absolutely, positively has to run at full CPU speed or not at
636 Judicious use of @code{sched_yield} function invocations by processes
637 with First Come First Served scheduling policy forms a good compromise
638 between Round Robin and First Come First Served.
640 To understand how scheduling works when processes of different scheduling
641 policies occupy the same absolute priority, you have to know the nitty
642 gritty details of how processes enter and exit the ready to run list.
644 In both cases, the ready to run list is organized as a true queue, where
645 a process gets pushed onto the tail when it becomes ready to run and is
646 popped off the head when the scheduler decides to run it. Note that
647 ready to run and running are two mutually exclusive states. When the
648 scheduler runs a process, that process is no longer ready to run and no
649 longer in the ready to run list. When the process stops running, it
650 may go back to being ready to run again.
652 The only difference between a process that is assigned the Round Robin
653 scheduling policy and a process that is assigned First Come First Serve
654 is that in the former case, the process is automatically booted off the
655 CPU after a certain amount of time. When that happens, the process goes
656 back to being ready to run, which means it enters the queue at the tail.
657 The time quantum we're talking about is small. Really small. This is
658 not your father's timesharing. For example, with the Linux kernel, the
659 round robin time slice is a thousand times shorter than its typical
660 time slice for traditional scheduling.
662 A process begins life with the same scheduling policy as its parent process.
663 Functions described in @ref{Basic Scheduling Functions} can change it.
665 Only a privileged process can set the scheduling policy of a process
666 that has absolute priority higher than 0.
668 @node Basic Scheduling Functions
669 @subsection Basic Scheduling Functions
671 This section describes functions in @theglibc{} for setting the
672 absolute priority and scheduling policy of a process.
674 @strong{Portability Note:} On systems that have the functions in this
675 section, the macro _POSIX_PRIORITY_SCHEDULING is defined in
678 For the case that the scheduling policy is traditional scheduling, more
679 functions to fine tune the scheduling are in @ref{Traditional Scheduling}.
681 Don't try to make too much out of the naming and structure of these
682 functions. They don't match the concepts described in this manual
683 because the functions are as defined by POSIX.1b, but the implementation
684 on systems that use @theglibc{} is the inverse of what the POSIX
685 structure contemplates. The POSIX scheme assumes that the primary
686 scheduling parameter is the scheduling policy and that the priority
687 value, if any, is a parameter of the scheduling policy. In the
688 implementation, though, the priority value is king and the scheduling
689 policy, if anything, only fine tunes the effect of that priority.
691 The symbols in this section are declared by including file @file{sched.h}.
693 @strong{Portability Note:} In POSIX, the @code{pid_t} arguments of the
694 functions below refer to process IDs. On Linux, they are actually
695 thread IDs, and control how specific threads are scheduled with
696 regards to the entire system. The resulting behavior does not conform
697 to POSIX. This is why the following description refers to tasks and
698 tasks IDs, and not processes and process IDs.
699 @c https://sourceware.org/bugzilla/show_bug.cgi?id=14829
701 @deftp {Data Type} {struct sched_param}
702 @standards{POSIX, sched.h}
703 This structure describes an absolute priority.
705 @item int sched_priority
706 absolute priority value
710 @deftypefun int sched_setscheduler (pid_t @var{pid}, int @var{policy}, const struct sched_param *@var{param})
711 @standards{POSIX, sched.h}
712 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
713 @c Direct syscall, Linux only.
715 This function sets both the absolute priority and the scheduling policy
718 It assigns the absolute priority value given by @var{param} and the
719 scheduling policy @var{policy} to the task with ID @var{pid},
720 or the calling task if @var{pid} is zero. If @var{policy} is
721 negative, @code{sched_setscheduler} keeps the existing scheduling policy.
723 The following macros represent the valid values for @var{policy}:
727 Traditional Scheduling
734 @c The Linux kernel code (in sched.c) actually reschedules the process,
735 @c but it puts it at the head of the run queue, so I'm not sure just what
736 @c the effect is, but it must be subtle.
738 On success, the return value is @code{0}. Otherwise, it is @code{-1}
739 and @code{ERRNO} is set accordingly. The @code{errno} values specific
740 to this function are:
746 The calling task does not have @code{CAP_SYS_NICE} permission and
747 @var{policy} is not @code{SCHED_OTHER} (or it's negative and the
748 existing policy is not @code{SCHED_OTHER}.
751 The calling task does not have @code{CAP_SYS_NICE} permission and its
752 owner is not the target task's owner. I.e., the effective uid of the
753 calling task is neither the effective nor the real uid of task
755 @c We need a cross reference to the capabilities section, when written.
759 There is no task with pid @var{pid} and @var{pid} is not zero.
764 @var{policy} does not identify an existing scheduling policy.
767 The absolute priority value identified by *@var{param} is outside the
768 valid range for the scheduling policy @var{policy} (or the existing
769 scheduling policy if @var{policy} is negative) or @var{param} is
770 null. @code{sched_get_priority_max} and @code{sched_get_priority_min}
771 tell you what the valid range is.
774 @var{pid} is negative.
781 @deftypefun int sched_getscheduler (pid_t @var{pid})
782 @standards{POSIX, sched.h}
783 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
784 @c Direct syscall, Linux only.
786 This function returns the scheduling policy assigned to the task with
787 ID @var{pid}, or the calling task if @var{pid} is zero.
789 The return value is the scheduling policy. See
790 @code{sched_setscheduler} for the possible values.
792 If the function fails, the return value is instead @code{-1} and
793 @code{errno} is set accordingly.
795 The @code{errno} values specific to this function are:
800 There is no task with pid @var{pid} and it is not zero.
803 @var{pid} is negative.
807 Note that this function is not an exact mate to @code{sched_setscheduler}
808 because while that function sets the scheduling policy and the absolute
809 priority, this function gets only the scheduling policy. To get the
810 absolute priority, use @code{sched_getparam}.
815 @deftypefun int sched_setparam (pid_t @var{pid}, const struct sched_param *@var{param})
816 @standards{POSIX, sched.h}
817 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
818 @c Direct syscall, Linux only.
820 This function sets a task's absolute priority.
822 It is functionally identical to @code{sched_setscheduler} with
823 @var{policy} = @code{-1}.
825 @c in fact, that's how it's implemented in Linux.
829 @deftypefun int sched_getparam (pid_t @var{pid}, struct sched_param *@var{param})
830 @standards{POSIX, sched.h}
831 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
832 @c Direct syscall, Linux only.
834 This function returns a task's absolute priority.
836 @var{pid} is the task ID of the task whose absolute priority you want
839 @var{param} is a pointer to a structure in which the function stores the
840 absolute priority of the task.
842 On success, the return value is @code{0}. Otherwise, it is @code{-1}
843 and @code{errno} is set accordingly. The @code{errno} values specific
844 to this function are:
849 There is no task with ID @var{pid} and it is not zero.
852 @var{pid} is negative.
859 @deftypefun int sched_get_priority_min (int @var{policy})
860 @standards{POSIX, sched.h}
861 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
862 @c Direct syscall, Linux only.
864 This function returns the lowest absolute priority value that is
865 allowable for a task with scheduling policy @var{policy}.
867 On Linux, it is 0 for SCHED_OTHER and 1 for everything else.
869 On success, the return value is @code{0}. Otherwise, it is @code{-1}
870 and @code{ERRNO} is set accordingly. The @code{errno} values specific
871 to this function are:
875 @var{policy} does not identify an existing scheduling policy.
880 @deftypefun int sched_get_priority_max (int @var{policy})
881 @standards{POSIX, sched.h}
882 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
883 @c Direct syscall, Linux only.
885 This function returns the highest absolute priority value that is
886 allowable for a task that with scheduling policy @var{policy}.
888 On Linux, it is 0 for SCHED_OTHER and 99 for everything else.
890 On success, the return value is @code{0}. Otherwise, it is @code{-1}
891 and @code{ERRNO} is set accordingly. The @code{errno} values specific
892 to this function are:
896 @var{policy} does not identify an existing scheduling policy.
901 @deftypefun int sched_rr_get_interval (pid_t @var{pid}, struct timespec *@var{interval})
902 @standards{POSIX, sched.h}
903 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
904 @c Direct syscall, Linux only.
906 This function returns the length of the quantum (time slice) used with
907 the Round Robin scheduling policy, if it is used, for the task with
910 It returns the length of time as @var{interval}.
911 @c We need a cross-reference to where timespec is explained. But that
912 @c section doesn't exist yet, and the time chapter needs to be slightly
913 @c reorganized so there is a place to put it (which will be right next
914 @c to timeval, which is presently misplaced). 2000.05.07.
916 With a Linux kernel, the round robin time slice is always 150
917 microseconds, and @var{pid} need not even be a real pid.
919 The return value is @code{0} on success and in the pathological case
920 that it fails, the return value is @code{-1} and @code{errno} is set
921 accordingly. There is nothing specific that can go wrong with this
922 function, so there are no specific @code{errno} values.
926 @deftypefun int sched_yield (void)
927 @standards{POSIX, sched.h}
928 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
929 @c Direct syscall on Linux; alias to swtch on HURD.
931 This function voluntarily gives up the task's claim on the CPU.
933 Technically, @code{sched_yield} causes the calling task to be made
934 immediately ready to run (as opposed to running, which is what it was
935 before). This means that if it has absolute priority higher than 0, it
936 gets pushed onto the tail of the queue of tasks that share its
937 absolute priority and are ready to run, and it will run again when its
938 turn next arrives. If its absolute priority is 0, it is more
939 complicated, but still has the effect of yielding the CPU to other
942 If there are no other tasks that share the calling task's absolute
943 priority, this function doesn't have any effect.
945 To the extent that the containing program is oblivious to what other
946 processes in the system are doing and how fast it executes, this
947 function appears as a no-op.
949 The return value is @code{0} on success and in the pathological case
950 that it fails, the return value is @code{-1} and @code{errno} is set
951 accordingly. There is nothing specific that can go wrong with this
952 function, so there are no specific @code{errno} values.
956 @node Extensible Scheduling
957 @subsection Extensible Scheduling
958 @cindex scheduling, extensible
960 The type @code{struct sched_attr} and the functions @code{sched_setattr}
961 and @code{sched_getattr} are used to implement scheduling policies with
962 multiple parameters (not just priority and niceness).
964 It is expected that these interfaces will be compatible with all future
967 For additional information about scheduling policies, consult consult
968 the manual pages @manpageurl{sched,7} and @manpageurl{sched_setattr,2}.
971 @strong{Note:} Calling the @code{sched_setattr} function is incompatible
972 with support for @code{PTHREAD_PRIO_PROTECT} mutexes.
974 @deftp {Data Type} {struct sched_attr}
975 @standards{Linux, sched.h}
976 The @code{sched_attr} structure describes a parameterized scheduling policy.
978 @strong{Portability note:} In the future, additional fields can be added
979 to @code{struct sched_attr} at the end, so that the size of this data
980 type changes. Do not use it in places where this matters, such as
981 structure fields in installed header files, where such a change could
982 impact the application binary interface (ABI).
984 The following generic fields are available.
988 The actually used size of the data structure. See the description of
989 the functions @code{sched_setattr} and @code{sched_getattr} below how this
990 field is used to support extension of @code{struct sched_attr} with
994 The scheduling policy. This field determines which fields in the
995 structure are used, and how the @code{sched_flags} field is interpreted.
998 Scheduling flags associated with the scheduling policy.
1001 In addition to the generic fields, policy-specific fields are available.
1002 For additional information, consult the manual page
1003 @manpageurl{sched_setattr,2}. @xref{Linux Kernel}.
1006 @deftypefun int sched_setaddr (pid_t @var{tid}, struct sched_attr *@var{attr}, unsigned int flags)
1007 @standards{Linux, sched.h}
1008 @safety{@mtsafe{}@assafe{}@acsafe{}}
1009 This functions applies the scheduling policy described by
1010 @code{*@var{attr}} to the thread @var{tid} (the value zero denotes the
1013 It is recommended to initialize unused fields to zero, either using
1014 @code{memset}, or using a structure initializer. The
1015 @code{@var{attr->size}} field should be set to @code{sizeof (struct
1016 sched_attr)}, to inform the kernel of the structure version in use.
1018 The @var{flags} argument must be zero. Other values may become
1019 available in the future.
1021 On failure, @code{sched_setattr} returns @math{-1} and sets
1022 @code{errno}. The following errors are related the way
1023 extensibility is handled.
1026 A field in @code{*@var{attr}} has a non-zero value, but is unknown to
1027 the kernel. The application could try to apply a modified policy, where
1028 more fields are zero.
1031 The policy in @code{@var{attr}->sched_policy} is unknown to the kernel,
1032 or flags are set in @code{@var{attr}->sched_flags} that the kernel does
1033 not know how to interpret. The application could try with fewer flags
1034 set, or a different scheduling policy.
1036 This error also occurs if @var{attr} is @code{NULL} or @var{flags} is
1040 The current thread is not sufficiently privileged to assign the policy,
1041 either because access to the policy is restricted in general, or because
1042 the current thread does not have the rights to change the scheduling
1043 policy of the thread @var{tid}.
1046 Other error codes depend on the scheduling policy.
1049 @deftypefun int sched_getaddr (pid_t @var{tid}, struct sched_attr *@var{attr}, unsigned int size, unsigned int flags)
1050 @standards{Linux, sched.h}
1051 @safety{@mtsafe{}@assafe{}@acsafe{}}
1052 This function obtains the scheduling policy of the thread @var{tid}
1053 (zero denotes the current thread) and store it in @code{*@var{attr}},
1054 which must have space for at least @var{size} bytes.
1056 The @var{flags} argument must be zero. Other values may become
1057 available in the future.
1059 Upon success, @code{@var{attr}->size} contains the size of the structure
1060 version used by the kernel. Fields with offsets greater or equal to
1061 @code{@var{attr}->size} are not updated by the kernel. To obtain
1062 predictable values for unknown fields, use @code{memset} to set
1063 all @var{size} bytes to zero prior to calling @code{sched_getattr}.
1065 On failure, @code{sched_getattr} returns @math{-1} and sets @code{errno}.
1066 If @code{errno} is @code{E2BIG}, this means that the buffer is not large
1067 large enough, and the application could retry with a larger buffer.
1070 @node Traditional Scheduling
1071 @subsection Traditional Scheduling
1072 @cindex scheduling, traditional
1074 This section is about the scheduling among processes whose absolute
1075 priority is 0. When the system hands out the scraps of CPU time that
1076 are left over after the processes with higher absolute priority have
1077 taken all they want, the scheduling described herein determines who
1078 among the great unwashed processes gets them.
1081 * Traditional Scheduling Intro::
1082 * Traditional Scheduling Functions::
1085 @node Traditional Scheduling Intro
1086 @subsubsection Introduction To Traditional Scheduling
1088 Long before there was absolute priority (See @ref{Absolute Priority}),
1089 Unix systems were scheduling the CPU using this system. When POSIX came
1090 in like the Romans and imposed absolute priorities to accommodate the
1091 needs of realtime processing, it left the indigenous Absolute Priority
1092 Zero processes to govern themselves by their own familiar scheduling
1095 Indeed, absolute priorities higher than zero are not available on many
1096 systems today and are not typically used when they are, being intended
1097 mainly for computers that do realtime processing. So this section
1098 describes the only scheduling many programmers need to be concerned
1101 But just to be clear about the scope of this scheduling: Any time a
1102 process with an absolute priority of 0 and a process with an absolute
1103 priority higher than 0 are ready to run at the same time, the one with
1104 absolute priority 0 does not run. If it's already running when the
1105 higher priority ready-to-run process comes into existence, it stops
1108 In addition to its absolute priority of zero, every process has another
1109 priority, which we will refer to as "dynamic priority" because it changes
1110 over time. The dynamic priority is meaningless for processes with
1111 an absolute priority higher than zero.
1113 The dynamic priority sometimes determines who gets the next turn on the
1114 CPU. Sometimes it determines how long turns last. Sometimes it
1115 determines whether a process can kick another off the CPU.
1117 In Linux, the value is a combination of these things, but mostly it
1118 just determines the length of the time slice. The higher a process'
1119 dynamic priority, the longer a shot it gets on the CPU when it gets one.
1120 If it doesn't use up its time slice before giving up the CPU to do
1121 something like wait for I/O, it is favored for getting the CPU back when
1122 it's ready for it, to finish out its time slice. Other than that,
1123 selection of processes for new time slices is basically round robin.
1124 But the scheduler does throw a bone to the low priority processes: A
1125 process' dynamic priority rises every time it is snubbed in the
1126 scheduling process. In Linux, even the fat kid gets to play.
1128 The fluctuation of a process' dynamic priority is regulated by another
1129 value: The ``nice'' value. The nice value is an integer, usually in the
1130 range -20 to 20, and represents an upper limit on a process' dynamic
1131 priority. The higher the nice number, the lower that limit.
1133 On a typical Linux system, for example, a process with a nice value of
1134 20 can get only 10 milliseconds on the CPU at a time, whereas a process
1135 with a nice value of -20 can achieve a high enough priority to get 400
1138 The idea of the nice value is deferential courtesy. In the beginning,
1139 in the Unix garden of Eden, all processes shared equally in the bounty
1140 of the computer system. But not all processes really need the same
1141 share of CPU time, so the nice value gave a courteous process the
1142 ability to refuse its equal share of CPU time that others might prosper.
1143 Hence, the higher a process' nice value, the nicer the process is.
1144 (Then a snake came along and offered some process a negative nice value
1145 and the system became the crass resource allocation system we know
1148 Dynamic priorities tend upward and downward with an objective of
1149 smoothing out allocation of CPU time and giving quick response time to
1150 infrequent requests. But they never exceed their nice limits, so on a
1151 heavily loaded CPU, the nice value effectively determines how fast a
1154 In keeping with the socialistic heritage of Unix process priority, a
1155 process begins life with the same nice value as its parent process and
1156 can raise it at will. A process can also raise the nice value of any
1157 other process owned by the same user (or effective user). But only a
1158 privileged process can lower its nice value. A privileged process can
1159 also raise or lower another process' nice value.
1161 @glibcadj{} functions for getting and setting nice values are described in
1162 @xref{Traditional Scheduling Functions}.
1164 @node Traditional Scheduling Functions
1165 @subsubsection Functions For Traditional Scheduling
1167 @pindex sys/resource.h
1168 This section describes how you can read and set the nice value of a
1169 process. All these symbols are declared in @file{sys/resource.h}.
1171 The function and macro names are defined by POSIX, and refer to
1172 "priority," but the functions actually have to do with nice values, as
1173 the terms are used both in the manual and POSIX.
1175 The range of valid nice values depends on the kernel, but typically it
1176 runs from @code{-20} to @code{20}. A lower nice value corresponds to
1177 higher priority for the process. These constants describe the range of
1182 @standards{BSD, sys/resource.h}
1183 The lowest valid nice value.
1186 @standards{BSD, sys/resource.h}
1187 The highest valid nice value.
1190 @deftypefun int getpriority (int @var{class}, int @var{id})
1191 @standards{BSD, sys/resource.h}
1192 @standards{POSIX, sys/resource.h}
1193 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1194 @c Direct syscall on UNIX. On HURD, calls _hurd_priority_which_map.
1195 Return the nice value of a set of processes; @var{class} and @var{id}
1196 specify which ones (see below). If the processes specified do not all
1197 have the same nice value, this returns the lowest value that any of them
1200 On success, the return value is @code{0}. Otherwise, it is @code{-1}
1201 and @code{errno} is set accordingly. The @code{errno} values specific
1202 to this function are:
1206 The combination of @var{class} and @var{id} does not match any existing
1210 The value of @var{class} is not valid.
1213 If the return value is @code{-1}, it could indicate failure, or it could
1214 be the nice value. The only way to make certain is to set @code{errno =
1215 0} before calling @code{getpriority}, then use @code{errno != 0}
1216 afterward as the criterion for failure.
1219 @deftypefun int setpriority (int @var{class}, int @var{id}, int @var{niceval})
1220 @standards{BSD, sys/resource.h}
1221 @standards{POSIX, sys/resource.h}
1222 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1223 @c Direct syscall on UNIX. On HURD, calls _hurd_priority_which_map.
1224 Set the nice value of a set of processes to @var{niceval}; @var{class}
1225 and @var{id} specify which ones (see below).
1227 The return value is @code{0} on success, and @code{-1} on
1228 failure. The following @code{errno} error condition are possible for
1233 The combination of @var{class} and @var{id} does not match any existing
1237 The value of @var{class} is not valid.
1240 The call would set the nice value of a process which is owned by a different
1241 user than the calling process (i.e., the target process' real or effective
1242 uid does not match the calling process' effective uid) and the calling
1243 process does not have @code{CAP_SYS_NICE} permission.
1246 The call would lower the process' nice value and the process does not have
1247 @code{CAP_SYS_NICE} permission.
1252 The arguments @var{class} and @var{id} together specify a set of
1253 processes in which you are interested. These are the possible values of
1258 @standards{BSD, sys/resource.h}
1259 One particular process. The argument @var{id} is a process ID (pid).
1262 @standards{BSD, sys/resource.h}
1263 All the processes in a particular process group. The argument @var{id} is
1264 a process group ID (pgid).
1267 @standards{BSD, sys/resource.h}
1268 All the processes owned by a particular user (i.e., whose real uid
1269 indicates the user). The argument @var{id} is a user ID (uid).
1272 If the argument @var{id} is 0, it stands for the calling process, its
1273 process group, or its owner (real uid), according to @var{class}.
1275 @deftypefun int nice (int @var{increment})
1276 @standards{BSD, unistd.h}
1277 @safety{@prelim{}@mtunsafe{@mtasurace{:setpriority}}@asunsafe{}@acsafe{}}
1278 @c Calls getpriority before and after setpriority, using the result of
1279 @c the first call to compute the argument for setpriority. This creates
1280 @c a window for a concurrent setpriority (or nice) call to be lost or
1281 @c exhibit surprising behavior.
1282 Increment the nice value of the calling process by @var{increment}.
1283 The return value is the new nice value on success, and @code{-1} on
1284 failure. In the case of failure, @code{errno} will be set to the
1285 same values as for @code{setpriority}.
1288 Here is an equivalent definition of @code{nice}:
1292 nice (int increment)
1294 int result, old = getpriority (PRIO_PROCESS, 0);
1295 result = setpriority (PRIO_PROCESS, 0, old + increment);
1297 return old + increment;
1306 @subsection Limiting execution to certain CPUs
1308 On a multi-processor system the operating system usually distributes
1309 the different processes which are runnable on all available CPUs in a
1310 way which allows the system to work most efficiently. Which processes
1311 and threads run can to some extend be controlled with the scheduling
1312 functionality described in the last sections. But which CPU finally
1313 executes which process or thread is not covered.
1315 There are a number of reasons why a program might want to have control
1316 over this aspect of the system as well:
1320 One thread or process is responsible for absolutely critical work
1321 which under no circumstances must be interrupted or hindered from
1322 making progress by other processes or threads using CPU resources. In
1323 this case the special process would be confined to a CPU which no
1324 other process or thread is allowed to use.
1327 The access to certain resources (RAM, I/O ports) has different costs
1328 from different CPUs. This is the case in NUMA (Non-Uniform Memory
1329 Architecture) machines. Preferably memory should be accessed locally
1330 but this requirement is usually not visible to the scheduler.
1331 Therefore forcing a process or thread to the CPUs which have local
1332 access to the most-used memory helps to significantly boost the
1336 In controlled runtimes resource allocation and book-keeping work (for
1337 instance garbage collection) is performance local to processors. This
1338 can help to reduce locking costs if the resources do not have to be
1339 protected from concurrent accesses from different processors.
1342 The POSIX standard up to this date is of not much help to solve this
1343 problem. The Linux kernel provides a set of interfaces to allow
1344 specifying @emph{affinity sets} for a process. The scheduler will
1345 schedule the thread or process on CPUs specified by the affinity
1346 masks. The interfaces which @theglibc{} define follow to some
1347 extent the Linux kernel interface.
1349 @deftp {Data Type} cpu_set_t
1350 @standards{GNU, sched.h}
1351 This data set is a bitset where each bit represents a CPU. How the
1352 system's CPUs are mapped to bits in the bitset is system dependent.
1353 The data type has a fixed size; in the unlikely case that the number
1354 of bits are not sufficient to describe the CPUs of the system a
1355 different interface has to be used.
1357 This type is a GNU extension and is defined in @file{sched.h}.
1360 To manipulate the bitset, to set and reset bits, a number of macros are
1361 defined. Some of the macros take a CPU number as a parameter. Here
1362 it is important to never exceed the size of the bitset. The following
1363 macro specifies the number of bits in the @code{cpu_set_t} bitset.
1365 @deftypevr Macro int CPU_SETSIZE
1366 @standards{GNU, sched.h}
1367 The value of this macro is the maximum number of CPUs which can be
1368 handled with a @code{cpu_set_t} object.
1371 The type @code{cpu_set_t} should be considered opaque; all
1372 manipulation should happen via the next four macros.
1374 @deftypefn Macro void CPU_ZERO (cpu_set_t *@var{set})
1375 @standards{GNU, sched.h}
1376 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1380 This macro initializes the CPU set @var{set} to be the empty set.
1382 This macro is a GNU extension and is defined in @file{sched.h}.
1385 @deftypefn Macro void CPU_SET (int @var{cpu}, cpu_set_t *@var{set})
1386 @standards{GNU, sched.h}
1387 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1392 This macro adds @var{cpu} to the CPU set @var{set}.
1394 The @var{cpu} parameter must not have side effects since it is
1395 evaluated more than once.
1397 This macro is a GNU extension and is defined in @file{sched.h}.
1400 @deftypefn Macro void CPU_CLR (int @var{cpu}, cpu_set_t *@var{set})
1401 @standards{GNU, sched.h}
1402 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1407 This macro removes @var{cpu} from the CPU set @var{set}.
1409 The @var{cpu} parameter must not have side effects since it is
1410 evaluated more than once.
1412 This macro is a GNU extension and is defined in @file{sched.h}.
1415 @deftypefn Macro int CPU_ISSET (int @var{cpu}, const cpu_set_t *@var{set})
1416 @standards{GNU, sched.h}
1417 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1422 This macro returns a nonzero value (true) if @var{cpu} is a member
1423 of the CPU set @var{set}, and zero (false) otherwise.
1425 The @var{cpu} parameter must not have side effects since it is
1426 evaluated more than once.
1428 This macro is a GNU extension and is defined in @file{sched.h}.
1432 CPU bitsets can be constructed from scratch or the currently installed
1433 affinity mask can be retrieved from the system.
1435 @deftypefun int sched_getaffinity (pid_t @var{pid}, size_t @var{cpusetsize}, cpu_set_t *@var{cpuset})
1436 @standards{GNU, sched.h}
1437 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1438 @c Wrapped syscall to zero out past the kernel cpu set size; Linux
1441 This function stores the CPU affinity mask for the process or thread
1442 with the ID @var{pid} in the @var{cpusetsize} bytes long bitmap
1443 pointed to by @var{cpuset}. If successful, the function always
1444 initializes all bits in the @code{cpu_set_t} object and returns zero.
1446 If @var{pid} does not correspond to a process or thread on the system
1447 the or the function fails for some other reason, it returns @code{-1}
1448 and @code{errno} is set to represent the error condition.
1452 No process or thread with the given ID found.
1455 The pointer @var{cpuset} does not point to a valid object.
1458 This function is a GNU extension and is declared in @file{sched.h}.
1461 Note that it is not portably possible to use this information to
1462 retrieve the information for different POSIX threads. A separate
1463 interface must be provided for that.
1465 @deftypefun int sched_setaffinity (pid_t @var{pid}, size_t @var{cpusetsize}, const cpu_set_t *@var{cpuset})
1466 @standards{GNU, sched.h}
1467 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1468 @c Wrapped syscall to detect attempts to set bits past the kernel cpu
1469 @c set size; Linux only.
1471 This function installs the @var{cpusetsize} bytes long affinity mask
1472 pointed to by @var{cpuset} for the process or thread with the ID @var{pid}.
1473 If successful the function returns zero and the scheduler will in the future
1474 take the affinity information into account.
1476 If the function fails it will return @code{-1} and @code{errno} is set
1481 No process or thread with the given ID found.
1484 The pointer @var{cpuset} does not point to a valid object.
1487 The bitset is not valid. This might mean that the affinity set might
1488 not leave a processor for the process or thread to run on.
1491 This function is a GNU extension and is declared in @file{sched.h}.
1494 @deftypefun int getcpu (unsigned int *cpu, unsigned int *node)
1495 @standards{Linux, <sched.h>}
1496 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1497 The @code{getcpu} function identifies the processor and node on which
1498 the calling thread or process is currently running and writes them into
1499 the integers pointed to by the @var{cpu} and @var{node} arguments. The
1500 processor is a unique nonnegative integer identifying a CPU. The node
1501 is a unique nonnegative integer identifying a NUMA node. When either
1502 @var{cpu} or @var{node} is @code{NULL}, nothing is written to the
1505 The return value is @code{0} on success and @code{-1} on failure. The
1506 following @code{errno} error condition is defined for this function:
1510 The operating system does not support this function.
1513 This function is Linux-specific and is declared in @file{sched.h}.
1516 @node Memory Resources
1517 @section Querying memory available resources
1519 The amount of memory available in the system and the way it is organized
1520 determines oftentimes the way programs can and have to work. For
1521 functions like @code{mmap} it is necessary to know about the size of
1522 individual memory pages and knowing how much memory is available enables
1523 a program to select appropriate sizes for, say, caches. Before we get
1524 into these details a few words about memory subsystems in traditional
1525 Unix systems will be given.
1528 * Memory Subsystem:: Overview about traditional Unix memory handling.
1529 * Query Memory Parameters:: How to get information about the memory
1533 @node Memory Subsystem
1534 @subsection Overview about traditional Unix memory handling
1536 @cindex address space
1537 @cindex physical memory
1538 @cindex physical address
1539 Unix systems normally provide processes virtual address spaces. This
1540 means that the addresses of the memory regions do not have to correspond
1541 directly to the addresses of the actual physical memory which stores the
1542 data. An extra level of indirection is introduced which translates
1543 virtual addresses into physical addresses. This is normally done by the
1544 hardware of the processor.
1546 @cindex shared memory
1547 Using a virtual address space has several advantages. The most important
1548 is process isolation. The different processes running on the system
1549 cannot interfere directly with each other. No process can write into
1550 the address space of another process (except when shared memory is used
1551 but then it is wanted and controlled).
1553 Another advantage of virtual memory is that the address space the
1554 processes see can actually be larger than the physical memory available.
1555 The physical memory can be extended by storage on an external media
1556 where the content of currently unused memory regions is stored. The
1557 address translation can then intercept accesses to these memory regions
1558 and make memory content available again by loading the data back into
1559 memory. This concept makes it necessary that programs which have to use
1560 lots of memory know the difference between available virtual address
1561 space and available physical memory. If the working set of virtual
1562 memory of all the processes is larger than the available physical memory
1563 the system will slow down dramatically due to constant swapping of
1564 memory content from the memory to the storage media and back. This is
1565 called ``thrashing''.
1569 @cindex page, memory
1570 A final aspect of virtual memory which is important and follows from
1571 what is said in the last paragraph is the granularity of the virtual
1572 address space handling. When we said that the virtual address handling
1573 stores memory content externally it cannot do this on a byte-by-byte
1574 basis. The administrative overhead does not allow this (leaving alone
1575 the processor hardware). Instead several thousand bytes are handled
1576 together and form a @dfn{page}. The size of each page is always a power
1577 of two bytes. The smallest page size in use today is 4096, with 8192,
1578 16384, and 65536 being other popular sizes.
1580 @node Query Memory Parameters
1581 @subsection How to get information about the memory subsystem?
1583 The page size of the virtual memory the process sees is essential to
1584 know in several situations. Some programming interfaces (e.g.,
1585 @code{mmap}, @pxref{Memory-mapped I/O}) require the user to provide
1586 information adjusted to the page size. In the case of @code{mmap} it is
1587 necessary to provide a length argument which is a multiple of the page
1588 size. Another place where the knowledge about the page size is useful
1589 is in memory allocation. If one allocates pieces of memory in larger
1590 chunks which are then subdivided by the application code it is useful to
1591 adjust the size of the larger blocks to the page size. If the total
1592 memory requirement for the block is close (but not larger) to a multiple
1593 of the page size the kernel's memory handling can work more effectively
1594 since it only has to allocate memory pages which are fully used. (To do
1595 this optimization it is necessary to know a bit about the memory
1596 allocator which will require a bit of memory itself for each block and
1597 this overhead must not push the total size over the page size multiple.)
1599 The page size traditionally was a compile time constant. But recent
1600 development of processors changed this. Processors now support
1601 different page sizes and they can possibly even vary among different
1602 processes on the same system. Therefore the system should be queried at
1603 runtime about the current page size and no assumptions (except about it
1604 being a power of two) should be made.
1606 @vindex _SC_PAGESIZE
1607 The correct interface to query about the page size is @code{sysconf}
1608 (@pxref{Sysconf Definition}) with the parameter @code{_SC_PAGESIZE}.
1609 There is a much older interface available, too.
1611 @deftypefun int getpagesize (void)
1612 @standards{BSD, unistd.h}
1613 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
1614 @c Obtained from the aux vec at program startup time. GNU/Linux/m68k is
1615 @c the exception, with the possibility of a syscall.
1616 The @code{getpagesize} function returns the page size of the process.
1617 This value is fixed for the runtime of the process but can vary in
1618 different runs of the application.
1620 The function is declared in @file{unistd.h}.
1623 Widely available on @w{System V} derived systems is a method to get
1624 information about the physical memory the system has. The call
1626 @vindex _SC_PHYS_PAGES
1629 sysconf (_SC_PHYS_PAGES)
1633 returns the total number of pages of physical memory the system has.
1634 This does not mean all this memory is available. This information can
1637 @vindex _SC_AVPHYS_PAGES
1640 sysconf (_SC_AVPHYS_PAGES)
1643 These two values help to optimize applications. The value returned for
1644 @code{_SC_AVPHYS_PAGES} is the amount of memory the application can use
1645 without hindering any other process (given that no other process
1646 increases its memory usage). The value returned for
1647 @code{_SC_PHYS_PAGES} is more or less a hard limit for the working set.
1648 If all applications together constantly use more than that amount of
1649 memory the system is in trouble.
1651 @Theglibc{} provides in addition to these already described way to
1652 get this information two functions. They are declared in the file
1653 @file{sys/sysinfo.h}. Programmers should prefer to use the
1654 @code{sysconf} method described above.
1656 @deftypefun {long int} get_phys_pages (void)
1657 @standards{GNU, sys/sysinfo.h}
1658 @safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{} @asulock{}}@acunsafe{@aculock{} @acsfd{} @acsmem{}}}
1659 @c This fopens a /proc file and scans it for the requested information.
1660 The @code{get_phys_pages} function returns the total number of pages of
1661 physical memory the system has. To get the amount of memory this number has to
1662 be multiplied by the page size.
1664 This function is a GNU extension.
1667 @deftypefun {long int} get_avphys_pages (void)
1668 @standards{GNU, sys/sysinfo.h}
1669 @safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{} @asulock{}}@acunsafe{@aculock{} @acsfd{} @acsmem{}}}
1670 The @code{get_avphys_pages} function returns the number of available pages of
1671 physical memory the system has. To get the amount of memory this number has to
1672 be multiplied by the page size.
1674 This function is a GNU extension.
1677 @node Processor Resources
1678 @section Learn about the processors available
1680 The use of threads or processes with shared memory allows an application
1681 to take advantage of all the processing power a system can provide. If
1682 the task can be parallelized the optimal way to write an application is
1683 to have at any time as many processes running as there are processors.
1684 To determine the number of processors available to the system one can
1687 @vindex _SC_NPROCESSORS_CONF
1690 sysconf (_SC_NPROCESSORS_CONF)
1694 which returns the number of processors the operating system configured.
1695 But it might be possible for the operating system to disable individual
1696 processors and so the call
1698 @vindex _SC_NPROCESSORS_ONLN
1701 sysconf (_SC_NPROCESSORS_ONLN)
1705 returns the number of processors which are currently online (i.e.,
1708 For these two pieces of information @theglibc{} also provides
1709 functions to get the information directly. The functions are declared
1710 in @file{sys/sysinfo.h}.
1712 @deftypefun int get_nprocs_conf (void)
1713 @standards{GNU, sys/sysinfo.h}
1714 @safety{@prelim{}@mtsafe{}@asunsafe{@ascuheap{} @asulock{}}@acunsafe{@aculock{} @acsfd{} @acsmem{}}}
1715 @c This function reads from from /sys using dir streams (single user, so
1716 @c no @mtasurace issue), and on some arches, from /proc using streams.
1717 The @code{get_nprocs_conf} function returns the number of processors the
1718 operating system configured.
1720 This function is a GNU extension.
1723 @deftypefun int get_nprocs (void)
1724 @standards{GNU, sys/sysinfo.h}
1725 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{@acsfd{}}}
1726 @c This function reads from /proc using file descriptor I/O.
1727 The @code{get_nprocs} function returns the number of available processors.
1729 This function is a GNU extension.
1732 @cindex load average
1733 Before starting more threads it should be checked whether the processors
1734 are not already overused. Unix systems calculate something called the
1735 @dfn{load average}. This is a number indicating how many processes were
1736 running. This number is an average over different periods of time
1737 (normally 1, 5, and 15 minutes).
1739 @deftypefun int getloadavg (double @var{loadavg}[], int @var{nelem})
1740 @standards{BSD, stdlib.h}
1741 @safety{@prelim{}@mtsafe{}@assafe{}@acsafe{@acsfd{}}}
1742 @c Calls host_info on HURD; on Linux, opens /proc/loadavg, reads from
1743 @c it, closes it, without cancellation point, and calls strtod_l with
1744 @c the C locale to convert the strings to doubles.
1745 This function gets the 1, 5 and 15 minute load averages of the
1746 system. The values are placed in @var{loadavg}. @code{getloadavg} will
1747 place at most @var{nelem} elements into the array but never more than
1748 three elements. The return value is the number of elements written to
1749 @var{loadavg}, or -1 on error.
1751 This function is declared in @file{stdlib.h}.