@node Resource Usage And Limitation, Non-Local Exits, Date and Time, Top

@c %MENU% Functions for examining resource usage and getting and setting limits

@chapter Resource Usage And Limitation

This chapter describes functions for examining how much of various kinds of

resources (CPU time, memory, etc.) a process has used and getting and setting

limits on future usage.

@menu

* Resource Usage::		Measuring various resources used.

* Limits on Resources::		Specifying limits on resource usage.

* Priority::			Reading or setting process run priority.

* Memory Resources::            Querying memory available resources.

* Processor Resources::         Learn about the processors available.

@end menu

@node Resource Usage

@section Resource Usage

@pindex sys/resource.h

The function @code{getrusage} and the data type @code{struct rusage}

are used to examine the resource usage of a process.  They are declared

in @file{sys/resource.h}.

@deftypefun int getrusage (int @var{processes}, struct rusage *@var{rusage})

@standards{BSD, sys/resource.h}

@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}

@c On HURD, this calls task_info 3 times.  On UNIX, it's a syscall.

This function reports resource usage totals for processes specified by

@var{processes}, storing the information in @code{*@var{rusage}}.

In most systems, @var{processes} has only two valid values:

@vtable @code

@item RUSAGE_SELF

@standards{BSD, sys/resource.h}

Just the current process.

@item RUSAGE_CHILDREN

@standards{BSD, sys/resource.h}

All child processes (direct and indirect) that have already terminated.

@end vtable

The return value of @code{getrusage} is zero for success, and @code{-1}

for failure.

@table @code

@item EINVAL

The argument @var{processes} is not valid.

@end table

@end deftypefun

One way of getting resource usage for a particular child process is with

the function @code{wait4}, which returns totals for a child when it

terminates.  @xref{BSD Wait Functions}.

@deftp {Data Type} {struct rusage}

@standards{BSD, sys/resource.h}

This data type stores various resource usage statistics.  It has the

following members, and possibly others:

@table @code

@item struct timeval ru_utime

Time spent executing user instructions.

@item struct timeval ru_stime

Time spent in operating system code on behalf of @var{processes}.

@item long int ru_maxrss

The maximum resident set size used, in kilobytes.  That is, the maximum

number of kilobytes of physical memory that @var{processes} used

simultaneously.

@item long int ru_ixrss

An integral value expressed in kilobytes times ticks of execution, which

indicates the amount of memory used by text that was shared with other

processes.

@item long int ru_idrss

An integral value expressed the same way, which is the amount of

unshared memory used for data.

@item long int ru_isrss

An integral value expressed the same way, which is the amount of

unshared memory used for stack space.

@item long int ru_minflt

The number of page faults which were serviced without requiring any I/O.

@item long int ru_majflt

The number of page faults which were serviced by doing I/O.

@item long int ru_nswap

The number of times @var{processes} was swapped entirely out of main memory.

@item long int ru_inblock

The number of times the file system had to read from the disk on behalf

of @var{processes}.

@item long int ru_oublock

The number of times the file system had to write to the disk on behalf

of @var{processes}.

@item long int ru_msgsnd

Number of IPC messages sent.

@item long int ru_msgrcv

Number of IPC messages received.

@item long int ru_nsignals

Number of signals received.

@item long int ru_nvcsw

The number of times @var{processes} voluntarily invoked a context switch

(usually to wait for some service).

@item long int ru_nivcsw

The number of times an involuntary context switch took place (because

a time slice expired, or another process of higher priority was

scheduled).

@end table

@end deftp

@code{vtimes} is a historical function that does some of what

@code{getrusage} does.  @code{getrusage} is a better choice.

@code{vtimes} and its @code{vtimes} data structure are declared in

@file{sys/vtimes.h}.

@pindex sys/vtimes.h

@deftypefun int vtimes (struct vtimes *@var{current}, struct vtimes *@var{child})

@standards{???, sys/vtimes.h}

@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}

@c Calls getrusage twice.

@code{vtimes} reports resource usage totals for a process.

If @var{current} is non-null, @code{vtimes} stores resource usage totals for

the invoking process alone in the structure to which it points.  If

@var{child} is non-null, @code{vtimes} stores resource usage totals for all

past children (which have terminated) of the invoking process in the structure

to which it points.

@deftp {Data Type} {struct vtimes}

This data type contains information about the resource usage of a process.

Each member corresponds to a member of the @code{struct rusage} data type

described above.

@table @code

@item vm_utime

User CPU time.  Analogous to @code{ru_utime} in @code{struct rusage}

@item vm_stime

System CPU time.  Analogous to @code{ru_stime} in @code{struct rusage}

@item vm_idsrss

Data and stack memory.  The sum of the values that would be reported as

@code{ru_idrss} and @code{ru_isrss} in @code{struct rusage}

@item vm_ixrss

Shared memory.  Analogous to @code{ru_ixrss} in @code{struct rusage}

@item vm_maxrss

Maximent resident set size.  Analogous to @code{ru_maxrss} in

@code{struct rusage}

@item vm_majflt

Major page faults.  Analogous to @code{ru_majflt} in @code{struct rusage}

@item vm_minflt

Minor page faults.  Analogous to @code{ru_minflt} in @code{struct rusage}

@item vm_nswap

Swap count.  Analogous to @code{ru_nswap} in @code{struct rusage}

@item vm_inblk

Disk reads.  Analogous to @code{ru_inblk} in @code{struct rusage}

@item vm_oublk

Disk writes.  Analogous to @code{ru_oublk} in @code{struct rusage}

@end table

@end deftp

The return value is zero if the function succeeds; @code{-1} otherwise.

@end deftypefun

An additional historical function for examining resource usage,

@code{vtimes}, is supported but not documented here.  It is declared in

@file{sys/vtimes.h}.

@node Limits on Resources

@section Limiting Resource Usage

@cindex resource limits

@cindex limits on resource usage

@cindex usage limits

You can specify limits for the resource usage of a process.  When the

process tries to exceed a limit, it may get a signal, or the system call

by which it tried to do so may fail, depending on the resource.  Each

process initially inherits its limit values from its parent, but it can

subsequently change them.

There are two per-process limits associated with a resource:

@cindex limit

@table @dfn

@item current limit

The current limit is the value the system will not allow usage to

exceed.  It is also called the ``soft limit'' because the process being

limited can generally raise the current limit at will.

@cindex current limit

@cindex soft limit

@item maximum limit

The maximum limit is the maximum value to which a process is allowed to

set its current limit.  It is also called the ``hard limit'' because

there is no way for a process to get around it.  A process may lower

its own maximum limit, but only the superuser may increase a maximum

limit.

@cindex maximum limit

@cindex hard limit

@end table

@pindex sys/resource.h

The symbols for use with @code{getrlimit}, @code{setrlimit},

@code{getrlimit64}, and @code{setrlimit64} are defined in

@file{sys/resource.h}.

@deftypefun int getrlimit (int @var{resource}, struct rlimit *@var{rlp})

@standards{BSD, sys/resource.h}

@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}

@c Direct syscall on most systems.

Read the current and maximum limits for the resource @var{resource}

and store them in @code{*@var{rlp}}.

The return value is @code{0} on success and @code{-1} on failure.  The

only possible @code{errno} error condition is @code{EFAULT}.

When the sources are compiled with @code{_FILE_OFFSET_BITS == 64} on a

32-bit system this function is in fact @code{getrlimit64}.  Thus, the

LFS interface transparently replaces the old interface.

@end deftypefun

@deftypefun int getrlimit64 (int @var{resource}, struct rlimit64 *@var{rlp})

@standards{Unix98, sys/resource.h}

@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}

@c Direct syscall on most systems, wrapper to getrlimit otherwise.

This function is similar to @code{getrlimit} but its second parameter is

a pointer to a variable of type @code{struct rlimit64}, which allows it

to read values which wouldn't fit in the member of a @code{struct

rlimit}.

If the sources are compiled with @code{_FILE_OFFSET_BITS == 64} on a

32-bit machine, this function is available under the name

@code{getrlimit} and so transparently replaces the old interface.

@end deftypefun

@deftypefun int setrlimit (int @var{resource}, const struct rlimit *@var{rlp})

@standards{BSD, sys/resource.h}

@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}

@c Direct syscall on most systems; lock-taking critical section on HURD.

Store the current and maximum limits for the resource @var{resource}

in @code{*@var{rlp}}.

The return value is @code{0} on success and @code{-1} on failure.  The

following @code{errno} error condition is possible:

@table @code

@item EPERM

@itemize @bullet

@item

The process tried to raise a current limit beyond the maximum limit.

@item

The process tried to raise a maximum limit, but is not superuser.

@end itemize

@end table

When the sources are compiled with @code{_FILE_OFFSET_BITS == 64} on a

32-bit system this function is in fact @code{setrlimit64}.  Thus, the

LFS interface transparently replaces the old interface.

@end deftypefun

@deftypefun int setrlimit64 (int @var{resource}, const struct rlimit64 *@var{rlp})

@standards{Unix98, sys/resource.h}

@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}

@c Wrapper for setrlimit or direct syscall.

This function is similar to @code{setrlimit} but its second parameter is

a pointer to a variable of type @code{struct rlimit64} which allows it

to set values which wouldn't fit in the member of a @code{struct

rlimit}.

If the sources are compiled with @code{_FILE_OFFSET_BITS == 64} on a

32-bit machine this function is available under the name

@code{setrlimit} and so transparently replaces the old interface.

@end deftypefun

@deftp {Data Type} {struct rlimit}

@standards{BSD, sys/resource.h}

This structure is used with @code{getrlimit} to receive limit values,

and with @code{setrlimit} to specify limit values for a particular process

and resource.  It has two fields:

@table @code

@item rlim_t rlim_cur

The current limit

@item rlim_t rlim_max

The maximum limit.

@end table

For @code{getrlimit}, the structure is an output; it receives the current

values.  For @code{setrlimit}, it specifies the new values.

@end deftp

For the LFS functions a similar type is defined in @file{sys/resource.h}.

@deftp {Data Type} {struct rlimit64}

@standards{Unix98, sys/resource.h}

This structure is analogous to the @code{rlimit} structure above, but

its components have wider ranges.  It has two fields:

@table @code

@item rlim64_t rlim_cur

This is analogous to @code{rlimit.rlim_cur}, but with a different type.

@item rlim64_t rlim_max

This is analogous to @code{rlimit.rlim_max}, but with a different type.

@end table

@end deftp

Here is a list of resources for which you can specify a limit.  Memory

and file sizes are measured in bytes.

@vtable @code

@item RLIMIT_CPU

@standards{BSD, sys/resource.h}

The maximum amount of CPU time the process can use.  If it runs for

longer than this, it gets a signal: @code{SIGXCPU}.  The value is

measured in seconds.  @xref{Operation Error Signals}.

@item RLIMIT_FSIZE

@standards{BSD, sys/resource.h}

The maximum size of file the process can create.  Trying to write a

larger file causes a signal: @code{SIGXFSZ}.  @xref{Operation Error

Signals}.

@item RLIMIT_DATA

@standards{BSD, sys/resource.h}

The maximum size of data memory for the process.  If the process tries

to allocate data memory beyond this amount, the allocation function

fails.

@item RLIMIT_STACK

@standards{BSD, sys/resource.h}

The maximum stack size for the process.  If the process tries to extend

its stack past this size, it gets a @code{SIGSEGV} signal.

@xref{Program Error Signals}.

@item RLIMIT_CORE

@standards{BSD, sys/resource.h}

The maximum size core file that this process can create.  If the process

terminates and would dump a core file larger than this, then no core

file is created.  So setting this limit to zero prevents core files from

ever being created.

@item RLIMIT_RSS

@standards{BSD, sys/resource.h}

The maximum amount of physical memory that this process should get.

This parameter is a guide for the system's scheduler and memory

allocator; the system may give the process more memory when there is a

surplus.

@item RLIMIT_MEMLOCK

@standards{BSD, sys/resource.h}

The maximum amount of memory that can be locked into physical memory (so

it will never be paged out).

@item RLIMIT_NPROC

@standards{BSD, sys/resource.h}

The maximum number of processes that can be created with the same user ID.

If you have reached the limit for your user ID, @code{fork} will fail

with @code{EAGAIN}.  @xref{Creating a Process}.

@item RLIMIT_NOFILE

@itemx RLIMIT_OFILE

@standardsx{RLIMIT_NOFILE, BSD, sys/resource.h}

The maximum number of files that the process can open.  If it tries to

open more files than this, its open attempt fails with @code{errno}

@code{EMFILE}.  @xref{Error Codes}.  Not all systems support this limit;

GNU does, and 4.4 BSD does.

@item RLIMIT_AS

@standards{Unix98, sys/resource.h}

The maximum size of total memory that this process should get.  If the

process tries to allocate more memory beyond this amount with, for

example, @code{brk}, @code{malloc}, @code{mmap} or @code{sbrk}, the

allocation function fails.

@item RLIM_NLIMITS

@standards{BSD, sys/resource.h}

The number of different resource limits.  Any valid @var{resource}

operand must be less than @code{RLIM_NLIMITS}.

@end vtable

@deftypevr Constant rlim_t RLIM_INFINITY

@standards{BSD, sys/resource.h}

This constant stands for a value of ``infinity'' when supplied as

the limit value in @code{setrlimit}.

@end deftypevr

The following are historical functions to do some of what the functions

above do.  The functions above are better choices.

@code{ulimit} and the command symbols are declared in @file{ulimit.h}.

@pindex ulimit.h

@deftypefun {long int} ulimit (int @var{cmd}, @dots{})

@standards{BSD, ulimit.h}

@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}

@c Wrapper for getrlimit, setrlimit or

@c sysconf(_SC_OPEN_MAX)->getdtablesize->getrlimit.

@code{ulimit} gets the current limit or sets the current and maximum

limit for a particular resource for the calling process according to the

command @var{cmd}.

If you are getting a limit, the command argument is the only argument.

If you are setting a limit, there is a second argument:

@code{long int} @var{limit} which is the value to which you are setting

the limit.

The @var{cmd} values and the operations they specify are:

@vtable @code

@item GETFSIZE

Get the current limit on the size of a file, in units of 512 bytes.

@item SETFSIZE

Set the current and maximum limit on the size of a file to @var{limit} *

512 bytes.

@end vtable

There are also some other @var{cmd} values that may do things on some

systems, but they are not supported.

Only the superuser may increase a maximum limit.

When you successfully get a limit, the return value of @code{ulimit} is

that limit, which is never negative.  When you successfully set a limit,

the return value is zero.  When the function fails, the return value is

@code{-1} and @code{errno} is set according to the reason:

@table @code

@item EPERM

A process tried to increase a maximum limit, but is not superuser.

@end table

@end deftypefun

@code{vlimit} and its resource symbols are declared in @file{sys/vlimit.h}.

@pindex sys/vlimit.h

@deftypefun int vlimit (int @var{resource}, int @var{limit})

@standards{BSD, sys/vlimit.h}

@safety{@prelim{}@mtunsafe{@mtasurace{:setrlimit}}@asunsafe{}@acsafe{}}

@c It calls getrlimit and modifies the rlim_cur field before calling

@c setrlimit.  There's a window for a concurrent call to setrlimit that

@c modifies e.g. rlim_max, which will be lost if running as super-user.

@code{vlimit} sets the current limit for a resource for a process.

@var{resource} identifies the resource:

@vtable @code

@item LIM_CPU

Maximum CPU time.  Same as @code{RLIMIT_CPU} for @code{setrlimit}.

@item LIM_FSIZE

Maximum file size.  Same as @code{RLIMIT_FSIZE} for @code{setrlimit}.

@item LIM_DATA

Maximum data memory.  Same as @code{RLIMIT_DATA} for @code{setrlimit}.

@item LIM_STACK

Maximum stack size.  Same as @code{RLIMIT_STACK} for @code{setrlimit}.

@item LIM_CORE

Maximum core file size.  Same as @code{RLIMIT_COR} for @code{setrlimit}.

@item LIM_MAXRSS

Maximum physical memory.  Same as @code{RLIMIT_RSS} for @code{setrlimit}.

@end vtable

The return value is zero for success, and @code{-1} with @code{errno} set

accordingly for failure:

@table @code

@item EPERM

The process tried to set its current limit beyond its maximum limit.

@end table

@end deftypefun

@node Priority

@section Process CPU Priority And Scheduling

@cindex process priority

@cindex cpu priority

@cindex priority of a process

When multiple processes simultaneously require CPU time, the system's

scheduling policy and process CPU priorities determine which processes

get it.  This section describes how that determination is made and

@glibcadj{} functions to control it.

It is common to refer to CPU scheduling simply as scheduling and a

process' CPU priority simply as the process' priority, with the CPU

resource being implied.  Bear in mind, though, that CPU time is not the

only resource a process uses or that processes contend for.  In some

cases, it is not even particularly important.  Giving a process a high

``priority'' may have very little effect on how fast a process runs with

respect to other processes.  The priorities discussed in this section

apply only to CPU time.

CPU scheduling is a complex issue and different systems do it in wildly

different ways.  New ideas continually develop and find their way into

the intricacies of the various systems' scheduling algorithms.  This

section discusses the general concepts, some specifics of systems

that commonly use @theglibc{}, and some standards.

For simplicity, we talk about CPU contention as if there is only one CPU

in the system.  But all the same principles apply when a processor has

multiple CPUs, and knowing that the number of processes that can run at

any one time is equal to the number of CPUs, you can easily extrapolate

the information.

The functions described in this section are all defined by the POSIX.1

and POSIX.1b standards (the @code{sched@dots{}} functions are POSIX.1b).

However, POSIX does not define any semantics for the values that these

functions get and set.  In this chapter, the semantics are based on the

Linux kernel's implementation of the POSIX standard.  As you will see,

the Linux implementation is quite the inverse of what the authors of the

POSIX syntax had in mind.

@menu

* Absolute Priority::               The first tier of priority.  Posix

* Realtime Scheduling::             Scheduling among the process nobility

* Basic Scheduling Functions::      Get/set scheduling policy, priority

* Traditional Scheduling::          Scheduling among the vulgar masses

* CPU Affinity::                    Limiting execution to certain CPUs

@end menu

@node Absolute Priority

@subsection Absolute Priority

@cindex absolute priority

@cindex priority, absolute

Every process has an absolute priority, and it is represented by a number.

The higher the number, the higher the absolute priority.

@cindex realtime CPU scheduling

On systems of the past, and most systems today, all processes have

absolute priority 0 and this section is irrelevant.  In that case,

@xref{Traditional Scheduling}.  Absolute priorities were invented to

accommodate realtime systems, in which it is vital that certain processes

be able to respond to external events happening in real time, which

means they cannot wait around while some other process that @emph{wants

to}, but doesn't @emph{need to} run occupies the CPU.

@cindex ready to run

@cindex preemptive scheduling

When two processes are in contention to use the CPU at any instant, the

one with the higher absolute priority always gets it.  This is true even if the

process with the lower priority is already using the CPU (i.e., the

scheduling is preemptive).  Of course, we're only talking about

processes that are running or ``ready to run,'' which means they are

ready to execute instructions right now.  When a process blocks to wait

for something like I/O, its absolute priority is irrelevant.

@cindex runnable process

@strong{NB:}  The term ``runnable'' is a synonym for ``ready to run.''

When two processes are running or ready to run and both have the same

absolute priority, it's more interesting.  In that case, who gets the

CPU is determined by the scheduling policy.  If the processes have

absolute priority 0, the traditional scheduling policy described in

@ref{Traditional Scheduling} applies.  Otherwise, the policies described

in @ref{Realtime Scheduling} apply.

You normally give an absolute priority above 0 only to a process that

can be trusted not to hog the CPU.  Such processes are designed to block

(or terminate) after relatively short CPU runs.

A process begins life with the same absolute priority as its parent

process.  Functions described in @ref{Basic Scheduling Functions} can

change it.

Only a privileged process can change a process' absolute priority to

something other than @code{0}.  Only a privileged process or the

target process' owner can change its absolute priority at all.

POSIX requires absolute priority values used with the realtime

scheduling policies to be consecutive with a range of at least 32.  On

Linux, they are 1 through 99.  The functions

@code{sched_get_priority_max} and @code{sched_set_priority_min} portably

tell you what the range is on a particular system.

@subsubsection Using Absolute Priority

One thing you must keep in mind when designing real time applications is

that having higher absolute priority than any other process doesn't

guarantee the process can run continuously.  Two things that can wreck a

good CPU run are interrupts and page faults.

Interrupt handlers live in that limbo between processes.  The CPU is

executing instructions, but they aren't part of any process.  An

interrupt will stop even the highest priority process.  So you must

allow for slight delays and make sure that no device in the system has

an interrupt handler that could cause too long a delay between

instructions for your process.

Similarly, a page fault causes what looks like a straightforward

sequence of instructions to take a long time.  The fact that other

processes get to run while the page faults in is of no consequence,

because as soon as the I/O is complete, the higher priority process will

kick them out and run again, but the wait for the I/O itself could be a

problem.  To neutralize this threat, use @code{mlock} or

@code{mlockall}.

There are a few ramifications of the absoluteness of this priority on a

single-CPU system that you need to keep in mind when you choose to set a

priority and also when you're working on a program that runs with high

absolute priority.  Consider a process that has higher absolute priority

than any other process in the system and due to a bug in its program, it

gets into an infinite loop.  It will never cede the CPU.  You can't run

a command to kill it because your command would need to get the CPU in

order to run.  The errant program is in complete control.  It controls

the vertical, it controls the horizontal.

There are two ways to avoid this: 1) keep a shell running somewhere with

a higher absolute priority or 2) keep a controlling terminal attached to

the high priority process group.  All the priority in the world won't

stop an interrupt handler from running and delivering a signal to the

process if you hit Control-C.

Some systems use absolute priority as a means of allocating a fixed

percentage of CPU time to a process.  To do this, a super high priority

privileged process constantly monitors the process' CPU usage and raises

its absolute priority when the process isn't getting its entitled share

and lowers it when the process is exceeding it.

@strong{NB:}  The absolute priority is sometimes called the ``static

priority.''  We don't use that term in this manual because it misses the

most important feature of the absolute priority:  its absoluteness.

@node Realtime Scheduling

@subsection Realtime Scheduling

@cindex realtime scheduling

Whenever two processes with the same absolute priority are ready to run,

the kernel has a decision to make, because only one can run at a time.

If the processes have absolute priority 0, the kernel makes this decision

as described in @ref{Traditional Scheduling}.  Otherwise, the decision

is as described in this section.

If two processes are ready to run but have different absolute priorities,

the decision is much simpler, and is described in @ref{Absolute

Priority}.

Each process has a scheduling policy.  For processes with absolute

priority other than zero, there are two available:

@enumerate

@item

First Come First Served

@item

Round Robin

@end enumerate

The most sensible case is where all the processes with a certain

absolute priority have the same scheduling policy.  We'll discuss that

first.

In Round Robin, processes share the CPU, each one running for a small

quantum of time (``time slice'') and then yielding to another in a

circular fashion.  Of course, only processes that are ready to run and

have the same absolute priority are in this circle.

In First Come First Served, the process that has been waiting the

longest to run gets the CPU, and it keeps it until it voluntarily

relinquishes the CPU, runs out of things to do (blocks), or gets

preempted by a higher priority process.

First Come First Served, along with maximal absolute priority and

careful control of interrupts and page faults, is the one to use when a

process absolutely, positively has to run at full CPU speed or not at

all.

Judicious use of @code{sched_yield} function invocations by processes

with First Come First Served scheduling policy forms a good compromise

between Round Robin and First Come First Served.

To understand how scheduling works when processes of different scheduling

policies occupy the same absolute priority, you have to know the nitty

gritty details of how processes enter and exit the ready to run list.

In both cases, the ready to run list is organized as a true queue, where

a process gets pushed onto the tail when it becomes ready to run and is

popped off the head when the scheduler decides to run it.  Note that

ready to run and running are two mutually exclusive states.  When the

scheduler runs a process, that process is no longer ready to run and no

longer in the ready to run list.  When the process stops running, it

may go back to being ready to run again.

The only difference between a process that is assigned the Round Robin

scheduling policy and a process that is assigned First Come First Serve

is that in the former case, the process is automatically booted off the

CPU after a certain amount of time.  When that happens, the process goes

back to being ready to run, which means it enters the queue at the tail.

The time quantum we're talking about is small.  Really small.  This is

not your father's timesharing.  For example, with the Linux kernel, the

round robin time slice is a thousand times shorter than its typical

time slice for traditional scheduling.

A process begins life with the same scheduling policy as its parent process.

Functions described in @ref{Basic Scheduling Functions} can change it.

Only a privileged process can set the scheduling policy of a process

that has absolute priority higher than 0.

@node Basic Scheduling Functions

@subsection Basic Scheduling Functions

This section describes functions in @theglibc{} for setting the

absolute priority and scheduling policy of a process.

@strong{Portability Note:}  On systems that have the functions in this

section, the macro _POSIX_PRIORITY_SCHEDULING is defined in

@file{<unistd.h>}.

For the case that the scheduling policy is traditional scheduling, more

functions to fine tune the scheduling are in @ref{Traditional Scheduling}.

Don't try to make too much out of the naming and structure of these

functions.  They don't match the concepts described in this manual

because the functions are as defined by POSIX.1b, but the implementation

on systems that use @theglibc{} is the inverse of what the POSIX

structure contemplates.  The POSIX scheme assumes that the primary

scheduling parameter is the scheduling policy and that the priority

value, if any, is a parameter of the scheduling policy.  In the

implementation, though, the priority value is king and the scheduling

policy, if anything, only fine tunes the effect of that priority.

The symbols in this section are declared by including file @file{sched.h}.

@deftp {Data Type} {struct sched_param}

@standards{POSIX, sched.h}

This structure describes an absolute priority.

@table @code

@item int sched_priority

absolute priority value

@end table

@end deftp

@deftypefun int sched_setscheduler (pid_t @var{pid}, int @var{policy}, const struct sched_param *@var{param})

@standards{POSIX, sched.h}

@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}

@c Direct syscall, Linux only.

This function sets both the absolute priority and the scheduling policy

for a process.

It assigns the absolute priority value given by @var{param} and the

scheduling policy @var{policy} to the process with Process ID @var{pid},

or the calling process if @var{pid} is zero.  If @var{policy} is

negative, @code{sched_setscheduler} keeps the existing scheduling policy.

The following macros represent the valid values for @var{policy}:

@vtable @code

@item SCHED_OTHER

Traditional Scheduling

@item SCHED_FIFO

First In First Out

@item SCHED_RR

Round Robin

@end vtable

@c The Linux kernel code (in sched.c) actually reschedules the process,

@c but it puts it at the head of the run queue, so I'm not sure just what

@c the effect is, but it must be subtle.

On success, the return value is @code{0}.  Otherwise, it is @code{-1}

and @code{ERRNO} is set accordingly.  The @code{errno} values specific

to this function are:

@table @code

@item EPERM

@itemize @bullet

@item

The calling process does not have @code{CAP_SYS_NICE} permission and

@var{policy} is not @code{SCHED_OTHER} (or it's negative and the

existing policy is not @code{SCHED_OTHER}.

@item

The calling process does not have @code{CAP_SYS_NICE} permission and its

owner is not the target process' owner.  I.e., the effective uid of the

calling process is neither the effective nor the real uid of process

@var{pid}.

@c We need a cross reference to the capabilities section, when written.

@end itemize

@item ESRCH

There is no process with pid @var{pid} and @var{pid} is not zero.

@item EINVAL

@itemize @bullet

@item

@var{policy} does not identify an existing scheduling policy.

@item

The absolute priority value identified by *@var{param} is outside the

valid range for the scheduling policy @var{policy} (or the existing

scheduling policy if @var{policy} is negative) or @var{param} is

null.  @code{sched_get_priority_max} and @code{sched_get_priority_min}

tell you what the valid range is.

@item

@var{pid} is negative.

@end itemize

@end table

@end deftypefun

@deftypefun int sched_getscheduler (pid_t @var{pid})

@standards{POSIX, sched.h}

@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}

@c Direct syscall, Linux only.

This function returns the scheduling policy assigned to the process with

Process ID (pid) @var{pid}, or the calling process if @var{pid} is zero.

The return value is the scheduling policy.  See

@code{sched_setscheduler} for the possible values.

If the function fails, the return value is instead @code{-1} and

@code{errno} is set accordingly.

The @code{errno} values specific to this function are:

@table @code

@item ESRCH

There is no process with pid @var{pid} and it is not zero.

@item EINVAL

@var{pid} is negative.

@end table

Note that this function is not an exact mate to @code{sched_setscheduler}

because while that function sets the scheduling policy and the absolute

priority, this function gets only the scheduling policy.  To get the

absolute priority, use @code{sched_getparam}.

@end deftypefun

@deftypefun int sched_setparam (pid_t @var{pid}, const struct sched_param *@var{param})

@standards{POSIX, sched.h}

@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}

@c Direct syscall, Linux only.

This function sets a process' absolute priority.

It is functionally identical to @code{sched_setscheduler} with

@var{policy} = @code{-1}.

@c in fact, that's how it's implemented in Linux.

@end deftypefun