svcadm(8)을 검색하려면 섹션에서 8 을 선택하고, 맨 페이지 이름에 svcadm을 입력하고 검색을 누른다.
priocntl(2)
priocntl(2) System Calls priocntl(2)
NAME
priocntl - process scheduler control
SYNOPSIS
#include <sys/types.h>
#include <sys/priocntl.h>
#include <sys/rtpriocntl.h>
#include <sys/tspriocntl.h>
#include <sys/iapriocntl.h>
#include <sys/fsspriocntl.h>
#include <sys/fxpriocntl.h>
long priocntl(idtype_t idtype, id_t id, int cmd, /* arg */ ...);
DESCRIPTION
The priocntl() function provides for control over the scheduling of an
active light weight process (LWP).
LWPs fall into distinct classes with a separate scheduling policy ap‐
plied to each class. The classes currently supported are the realtime
class, the time-sharing class, the fair-share class, and the fixed-pri‐
ority class. The characteristics of these classes are described under
the corresponding headings below.
The class attribute of an LWP is inherited across the fork(2) function
and the exec(2) family of functions. The priocntl() function can be
used to dynamically change the class and other scheduling parameters
associated with a running LWP or set of LWPs given the appropriate per‐
missions as explained below.
In the default configuration, a runnable realtime LWP runs before any
other LWP. Therefore, inappropriate use of realtime LWP can have a dra‐
matic negative impact on system performance.
The priocntl() function provides an interface for specifying a process,
set of processes, or an LWP to which the function applies. The prioc‐
ntlset(2) function provides the same functions as priocntl(), but al‐
lows a more general interface for specifying the set of LWPs to which
the function is to apply.
For priocntl(), the idtype and id arguments are used together to spec‐
ify the set of LWPs. The interpretation of id depends on the value of
idtype. The possible values for idtype and corresponding interpreta‐
tions of id are as follows:
P_ALL The priocntl() function applies to all existing LWPs. The
value of id is ignored. The permission restrictions de‐
scribed below still apply.
P_CID The id argument is a class ID (returned by the priocntl()
PC_GETCID command as explained below). The priocntl() func‐
tion applies to all LWPs in the specified class.
P_CTID The id argument is a process contract ID. The priocntl()
function applies to all LWPs with this process contract ID.
P_GID The id argument is a group ID. The priocntl() function ap‐
plies to all LWPs with this effective group ID.
P_LWPID The id argument is an LWP ID. The priocntl() function ap‐
plies to the LWP with the specified ID within the calling
process.
P_PGID The id argument is a process group ID. The priocntl() func‐
tion applies to all LWPs currently associated with
processes in the specified process group.
P_PID The id argument is a process ID specifying a single
process. The priocntl() function applies to all LWPs cur‐
rently associated with the specified process.
P_PPID The id argument is a parent process ID. The priocntl()
function applies to all LWPs currently associated with
processes with the specified parent process ID.
P_PROJID The id argument is a project ID. The priocntl() function
applies to all LWPs with this project ID.
P_SID The id argument is a session ID. The priocntl() function
applies to all LWPs currently associated with processes in
the specified session.
P_TASKID The id argument is a task ID. The priocntl() function ap‐
plies to all LWPs currently associated with processes in
the specified task.
P_UID The id argument is a user ID. The priocntl() function ap‐
plies to all LWPs with this effective user ID.
P_ZONEID The id argument is a zone ID. The priocntl() function ap‐
plies to all LWPs with this zone ID.
An id value of P_MYID can be used in conjunction with the idtype value
to specify the LWP ID, parent process ID, process group ID, session ID,
task ID, class ID, user ID, group ID, project ID, zone ID, or process
contract ID of the calling LWP.
To change the scheduling parameters of an LWP (using the PC_SETPARMS or
PC_SETXPARMS command as explained below), the real or effective user ID
of the LWP calling priocntl() must match the real or the calling LWP
must have sufficient privileges. These are the minimum permission re‐
quirements enforced for all classes. An individual class might impose
additional permissions requirements when setting LWPs to that class
and/or when setting class-specific scheduling parameters.
Two special scheduling classes, SYS and SDC, exist for the purpose of
scheduling the execution of certain special system processes (such as
the swapper process). It is not possible to change the class of any LWP
to SYS or SDC. In addition, any processes in the SYS of SDC classes
that are included in a specified set of processes are disregarded by
priocntl(). For example, an idtype of P_UID and an id value of 0 would
specify all processes with a user ID of 0 except processes in the SYS
and SDC classes and (if changing the parameters using PC_SETPARMS or
PC_SETXPARMS) the init(8) process.
The init process is a special case. For a priocntl() call to change the
class or other scheduling parameters of the init process (process ID
1), it must be the only process specified by idtype and id. The init
process can be assigned to any class configured on the system, but the
time-sharing class is almost always the appropriate choice. (Other
choices might be highly undesirable.)
The data type and value of arg are specific to the type of command
specified by cmd.
A pcinfo_t structure with the following members, defined in <sys/prioc‐
ntl.h>, is used by the PC_GETCID and PC_GETCLINFO commands.
id_t pc_cid; /* Class id */
char pc_clname[PC_CLNMSZ]; /* Class name */
int pc_clinfo[PC_CLINFOSZ]; /* Class information */
The pc_cid member is a class ID returned by the priocntl() PC_GETCID
command.
The pc_clname member is a buffer of size PC_CLNMSZ, defined in
<sys/priocntl.h>, used to hold the class name: RT for realtime, TS for
time-sharing, IA for interactive, FSS for fair-share, or FX for fixed-
priority. Each string is null-terminated.
The pc_clinfo member is a buffer of size PC_CLINFOSZ, defined in
<sys/priocntl.h>, used to return data describing the attributes of a
specific class. The format of this data is class-specific and is de‐
scribed under the appropriate heading (REALTIME CLASS, TIME-SHARING
CLASS, INTERACTIVE CLASS, FAIR-SHARE CLASS, or FIXED-PRIORITY CLASS)
below.
A pcparms_t structure with the following members, defined in <sys/pri‐
ocntl.h>, is used by the PC_SETPARMS and PC_GETPARMS commands.
id_t pc_cid; /* LWP class */
int pc_clparms[PC_CLPARMSZ]; /* Class-specific params */
The pc_cid member is a class ID returned by the priocntl() PC_GETCID
command. The special class ID PC_CLNULL can also be assigned to pc_cid
when using the PC_GETPARMS command as explained below.
The pc_clparms buffer holds class-specific scheduling parameters. The
format of this parameter data for a particular class is described under
the appropriate heading below. PC_CLPARMSZ is the length of the
pc_clparms buffer and is defined in <sys/priocntl.h>.
The PC_SETXPARMS and PC_GETXPARMS commands exploit the varargs declara‐
tion of priocntl(). The argument following the command code is a class
name: RT for realtime, TS for time-sharing, IA for interactive, FSS for
fair-share, or FX for fixed-priority. The parameters after the class
name build a chain of (key, value) pairs, where the key determines the
meaning of the value within the pair. When using PC_GETXPARMS, the
value associated with the key is always a pointer to a scheduling para‐
meter. In contrast, when using PC_SETXPARMS the scheduling parameter is
given as a direct value. A key value of 0 terminates the sequence and
all further keys or values are ignored.
The PC_SETXPARMS and PC_GETXPARMS commands are more flexible than
PC_SETPARMS and PC_GETPARMS and should replace PC_SETPARMS and PC_GET‐
PARMS on a long-term basis.
COMMANDS
Available priocntl() commands are:
PC_ADMIN
This command provides functionality needed for the implementation
of the dispadmin(8) utility. It is not intended for general use by
other applications.
PC_DONICE
Set or get nice value of the specified LWP(s) associated with the
specified process(es). When this command is used with the idtype of
P_LWPID, it sets the nice value of the LWP. The arg argument points
to a structure of type pcnice_t. The pc_val member specifies the
nice value and the pc_op specifies the type of the operation.
When pc_op is set to PC_GETNICE, priocntl() sets the pc_val to the
highest priority (lowest numerical value) pertaining to any of the
specified LWPs.
When pc_op is set to PC_SETNICE, priocntl() sets the nice value of
all LWPs in the specified set to the value specified in pc_val mem‐
ber of pcnice_t structure.
The priocntl() function returns −1 with errno set to EPERM if the
calling LWP doesn't have appropriate permissions to set or get nice
values for one or more of the target LWPs. If priocntl() encounters
an error other than permissions, it does not continue through the
set of target LWPs but returns the error immediately.
PC_GETCID
Get class ID and class attributes for a specific class given the
class name. The idtype and id arguments are ignored. If arg is non-
null, it points to a structure of type pcinfo_t. The pc_clname
buffer contains the name of the class whose attributes you are get‐
ting.
On success, the class ID is returned in pc_cid, the class attrib‐
utes are returned in the pc_clinfo buffer, and the priocntl() call
returns the total number of classes configured in the system (in‐
cluding the sys class). If the class specified by pc_clname is in‐
valid or is not currently configured, the priocntl() call returns
−1 with errno set to EINVAL. The format of the attribute data re‐
turned for a given class is defined in the <sys/rtpriocntl.h>,
<sys/tspriocntl.h>, <sys/iapriocntl.h>, <sys/fsspriocntl.h>, or
<sys/fxpriocntl.h> header and described under the appropriate head‐
ing below.
If arg is a null pointer, no attribute data is returned but the
priocntl() call still returns the number of configured classes.
PC_GETCLINFO
Get class name and class attributes for a specific class given
class ID. The idtype and id arguments are ignored. If arg is non-
null, it points to a structure of type pcinfo_t. The pc_cid member
is the class ID of the class whose attributes you are getting.
On success, the class name is returned in the pc_clname buffer, the
class attributes are returned in the pc_clinfo buffer, and the pri‐
ocntl() call returns the total number of classes configured in the
system (including the sys class). The format of the attribute data
returned for a given class is defined in the <sys/rtpriocntl.h>,
<sys/tspriocntl.h>, <sys/iapriocntl.h>, <sys/fsspriocntl.h>, or
<sys/fxpriocntl.h> header and described under the appropriate head‐
ing below.
If arg is a null pointer, no attribute data is returned but the
priocntl() call still returns the number of configured classes.
PC_GETPARMS
Get the class and/or class-specific scheduling parameters of an
LWP. The arg member points to a structure of type pcparms_t.
If pc_cid specifies a configured class and a single LWP belonging
to that class is specified by the idtype and id values or the proc‐
set structure, then the scheduling parameters of that LWP are re‐
turned in the pc_clparms buffer. If the LWP specified does not ex‐
ist or does not belong to the specified class, the priocntl() call
returns −1 with errno set to ESRCH.
If pc_cid specifies a configured class and a set of LWPs is speci‐
fied, the scheduling parameters of one of the specified LWP belong‐
ing to the specified class are returned in the pc_clparms buffer
and the priocntl() call returns the process ID of the selected LWP.
The criteria for selecting an LWP to return in this case is class-
dependent. If none of the specified LWPs exist or none of them be‐
long to the specified class, the priocntl() call returns −1 with
errno set to ESRCH.
If pc_cid is PC_CLNULL and a single LWP is specified, the class of
the specified LWP is returned in pc_cid and its scheduling parame‐
ters are returned in the pc_clparms buffer.
PC_GETXPARMS
Get the class or class-specific scheduling parameters of an LWP.
The class name (first argument after PC_GETXPARMS) specifies the
class and the (key, value) pair sequence contains a pointer to the
class-specific parameters. The keys and the types of the class-spe‐
cific parameter data are described below and can also be found in
the class-specific headers <sys/rtpriocntl.h>, <sys/tspriocntl.h>,
<sys/iapriocntl.h>, <sys/fsspriocntl.h>, and <sys/fxpriocntl.h>. If
the specified class is a configured class and a single LWP belong‐
ing to that class is specified by the idtype and id values or the
procset structure, then the scheduling parameters of that LWP are
returned in the given (key, value) pair buffers. If the LWP speci‐
fied does not exist or does not belong to the specified class, pri‐
ocntl() returns −1 and errno is set to ESRCH.
If the class name specifies a configured class and a set of LWPs is
given, the scheduling parameters of one of the specified LWPs be‐
longing to the specified class are returned and the priocntl() call
returns the process ID of the selected LWP. The criteria for se‐
lecting an LWP to return in this case is class-dependent. If none
of the specified LWPs exist or none of them belong to the specified
class, priocntl() returns −1 and errno is set to ESRCH.
If the class name is a null pointer, a single process or LWP is
specified, and a (key, value) pair for a class name request is
given, priocntl() fills the buffer pointed to by value with the
class name of the specified process or LWP. The key for the class
name request is PC_KY_CLNAME and the class name buffer should be
declared as:
char pc_clname[PC_CLNMSZ]; /* Class name */
PC_SETPARMS
Set the class and class-specific scheduling parameters of the spec‐
ified LWP(s) associated with the specified process(es). When this
command is used with the idtype of P_LWPID, it will set the class
and class-specific scheduling parameters of the LWP. The arg argu‐
ment points to a structure of type pcparms_t. The pc_cid member
specifies the class you are setting and the pc_clparms buffer con‐
tains the class-specific parameters you are setting. The format of
the class-specific parameter data is defined in the <sys/rtprioc‐
ntl.h>, <sys/tspriocntl.h>, <sys/iapriocntl.h>, <sys/fssprioc‐
ntl.h>, or <sys/fxpriocntl.h> header and described under the appro‐
priate class heading below.
When setting parameters for a set of LWPs, priocntl() acts on the
LWPs in the set in an implementation-specific order. If priocntl()
encounters an error for one or more of the target processes, it
might or might not continue through the set of LWPs, depending on
the nature of the error. If the error is related to permissions
(EPERM), priocntl() continues through the LWP set, resetting the
parameters for all target LWPs for which the calling LWP has appro‐
priate permissions. The priocntl() function then returns −1 with
errno set to EPERM to indicate that the operation failed for one or
more of the target LWPs. If priocntl() encounters an error other
than permissions, it does not continue through the set of target
LWPs but returns the error immediately.
PC_SETXPARMS
Set the class and class-specific scheduling parameters of the spec‐
ified LWP(s) associated with the specified process(es). When this
command is used with P_LWPID as idtype, it will set the class and
class-specific scheduling parameters of the LWP. The class name
(first argument after PC_SETXPARMS) specifies the class to be
changed and the following (key, value) pair sequence contains the
class-specific parameters to be changed. Only those (key,value)
pairs whose scheduling behavior is to change must be specified. The
keys and the types of the class-specific parameter data are de‐
scribed below and can also be found in the class-specific header
files <sys/rtpriocntl.h>, <sys/tspriocntl.h>, <sys/iapriocntl.h>,
<sys/fsspriocntl.h>, and <sys/fxpriocntl.h>.
When setting parameters for a set of LWPs, priocntl() acts on the
LWPs in the set in an implementation-specific order. If priocntl()
encounters an error for one or more of the target processes, it
might or might not continue through the set of LWPs, depending on
the nature of the error. If the error is related to permissions
(EPERM), priocntl() continues to reset the parameters for all tar‐
get LWPs where the calling LWP has appropriate permissions. The
priocntl() function returns −1 and errno is set to EPERM when the
operation failed for one or more of the target LWPs. All errors
other than EPERM result in an immediate termination of priocntl().
REALTIME CLASS
The realtime class provides a fixed priority preemptive scheduling pol‐
icy for those LWPS requiring fast and deterministic response and ab‐
solute user/application control of scheduling priorities. If the real‐
time class is configured in the system, it should have exclusive con‐
trol of the highest range of scheduling priorities on the system. This
ensures that a runnable realtime LWP is given CPU service before any
LWP belonging to any other class.
The realtime class has a range of realtime priority (rt_pri) values
that can be assigned to an LWP within the class. Realtime priorities
range from 0 to x, where the value of x is configurable and can be de‐
termined for a specific installation by using the priocntl() PC_GETCID
or PC_GETCLINFO command.
The realtime scheduling policy is a fixed priority policy. The schedul‐
ing priority of a realtime LWP is never changed except as the result of
an explicit request by the user/application to change the rt_pri value
of the LWP.
For an LWP in the realtime class, the rt_pri value is, for all practi‐
cal purposes, equivalent to the scheduling priority of the LWP. The
rt_pri value completely determines the scheduling priority of a real‐
time LWP relative to other LWPs within its class. Numerically higher
rt_pri values represent higher priorities. Since the realtime class
controls the highest range of scheduling priorities in the system, it
is guaranteed that the runnable realtime LWP with the highest rt_pri
value is always selected to run before any other LWPs in the system.
In addition to providing control over priority, priocntl() provides for
control over the length of the time quantum allotted to the LWP in the
realtime class. The time quantum value specifies the maximum amount of
time an LWP can run assuming that it does not complete or enter a re‐
source or event wait state (sleep). If another LWP becomes runnable at
a higher priority, the currently running LWP might be preempted before
receiving its full time quantum.
The realtime quantum signal can be used for the notification of runaway
realtime processes about the consumption of their time quantum. Those
processes, which are monitored by the realtime time quantum signal, re‐
ceive the configured signal in the event of time quantum expiration.
The default value (0) of the time quantum signal will denote no signal
delivery and a positive value will denote the delivery of the signal
specified by the value. The realtime quantum signal can be set with the
priocntl() PC_SETXPARMS command and displayed with the priocntl()
PC_GETXPARMS command as explained below.
The system's process scheduler keeps the runnable realtime LWPs on a
set of scheduling queues. There is a separate queue for each configured
realtime priority and all realtime LWPs with a given rt_pri value are
kept together on the appropriate queue. The LWPs on a given queue are
ordered in FIFO order (that is, the LWP at the front of the queue has
been waiting longest for service and receives the CPU first). Realtime
LWPs that wake up after sleeping, LWPs that change to the realtime
class from some other class, LWPs that have used their full time quan‐
tum, and runnable LWPs whose priority is reset by priocntl() are all
placed at the back of the appropriate queue for their priority. An LWP
that is preempted by a higher priority LWP remains at the front of the
queue (with whatever time is remaining in its time quantum) and runs
before any other LWP at this priority. Following a fork(2) function
call by a realtime LWP, the parent LWP continues to run while the child
LWP (which inherits its parent's rt_pri value) is placed at the back of
the queue.
A rtinfo_t structure with the following members, defined in <sys/rtpri‐
ocntl.h>, defines the format used for the attribute data for the real‐
time class.
short rt_maxpri; /* Maximum realtime priority */
The priocntl() PC_GETCID and PC_GETCLINFO commands return realtime
class attributes in the pc_clinfo buffer in this format.
The rt_maxpri member specifies the configured maximum rt_pri value for
the realtime class. If rt_maxpri is x, the valid realtime priorities
range from 0 to x.
A rtparms_t structure with the following members, defined in <sys/rt‐
priocntl.h>, defines the format used to specify the realtime class-spe‐
cific scheduling parameters of an LWP.
short rt_pri; /* Real-Time priority */
uint_t rt_tqsecs; /* Seconds in time quantum */
int rt_tqnsecs; /* Additional nanoseconds in quantum */
When using the priocntl() PC_SETPARMS or PC_GETPARMS commands, if
pc_cid specifies the realtime class, the data in the pc_clparms buffer
are in this format.
These commands can be used to set the realtime priority to the speci‐
fied value or get the current rt_pri value. Setting the rt_pri value of
an LWP that is currently running or runnable (not sleeping) causes the
LWP to be placed at the back of the scheduling queue for the specified
priority. The LWP is placed at the back of the appropriate queue re‐
gardless of whether the priority being set is different from the previ‐
ous rt_pri value of the LWP. A running LWP can voluntarily release the
CPU and go to the back of the scheduling queue at the same priority by
resetting its rt_pri value to its current realtime priority value. To
change the time quantum of an LWP without setting the priority or af‐
fecting the LWP's position on the queue, the rt_pri member should be
set to the special value RT_NOCHANGE, defined in <sys/rtpriocntl.h>.
Specifying RT_NOCHANGE when changing the class of an LWP to realtime
from some other class results in the realtime priority being set to 0.
For the priocntl() PC_GETPARMS command, if pc_cid specifies the real‐
time class and more than one realtime LWP is specified, the scheduling
parameters of the realtime LWP with the highest rt_pri value among the
specified LWPs are returned and the LWP ID of this LWP is returned by
the priocntl() call. If there is more than one LWP sharing the highest
priority, the one returned is implementation-dependent.
The rt_tqsecs and rt_tqnsecs members are used for getting or setting
the time quantum associated with an LWP or group of LWPs. rt_tqsecs is
the number of seconds in the time quantum and rt_tqnsecs is the number
of additional nanoseconds in the quantum. For example, setting
rt_tqsecs to 2 and rt_tqnsecs to 500,000,000 (decimal) would result in
a time quantum of two and one-half seconds. Specifying a value of
1,000,000,000 or greater in the rt_tqnsecs member results in an error
return with errno set to EINVAL. Although the resolution of the
tq_nsecs member is very fine, the specified time quantum length is
rounded up by the system to the next integral multiple of the system
clock's resolution. The maximum time quantum that can be specified is
implementation-specific and equal to INT_MAX ticks. The INT_MAX value
is defined in <limits.h>. Requesting a quantum greater than this maxi‐
mum results in an error return with errno set to ERANGE, although infi‐
nite quantums can be requested using a special value as explained be‐
low. Requesting a time quantum of 0 by setting both rt_tqsecs and
rt_tqnsecs to 0 results in an error return with errno set to EINVAL.
The rt_tqnsecs member can also be set to one of the following special
values defined in <sys/rtpriocntl.h>, in which case the value of
rt_tqsecs is ignored:
RT_TQINF Set an infinite time quantum.
RT_TQDEF Set the time quantum to the default for this priority
(see rt_dptbl(5)).
RT_NOCHANGE Do not set the time quantum. This value is useful when
you wish to change the realtime priority of an LWP with‐
out affecting the time quantum. Specifying this value
when changing the class of an LWP to realtime from some
other class is equivalent to specifying RT_TQDEF.
When using the priocntl() PC_SETXPARMS or PC_GETXPARMS commands, the
first argument after the command code must be the class name of the re‐
altime class (RT). The next arguments are formed as (key, value) pairs,
terminated by a 0 key. The definition for the keys of the realtime
class can be found in <sys/rtpriocntl.h>. A repeated specification of
the same key results in an error return and errno set to EINVAL.
tab() box; lw(1.44i) |lw(1.08i) |lw(2.98i) lw(1.44i) |lw(1.08i)
|lw(2.98i) KeyValue TypeDescription _ RT_KY_PRIpri_trealtime priority _
RT_KY_TQSECSuint_tseconds in time quantum _ RT_KY_TQNSECSintnanoseconds
in time quantum _ RT_KY_TQSIGintrealtime time quantum signal
When using the priocntl() PC_GETXPARMS command, the value associated
with the key is always a pointer to a scheduling parameter of the value
type shown in the table above. In contrast, when using the priocntl()
PC_SETXPARMS command, the scheduling parameter is given as a direct
value.
A priocntl() PC_SETXPARMS command with the class name (RT) and without
a following (key, value) pair will set or reset all realtime scheduling
parameters of the target process(es) to their default values. Changing
the class of an LWP to realtime from some other class causes the para‐
meters to be set to their default values. The default realtime priority
(RT_KY_PRI) is 0. A default time quantum (RT_TQDEF) is assigned to each
priority class (see rt_dptbl(5)). The default realtime time quantum
signal (RT_KY_TQSIG) is 0.
The value associated with RT_KY_TQSECS is the number of seconds in the
time quantum. The value associated with RT_KY_TQNSECS is the number of
nanoseconds in the quantum. Specifying a value of 1,000,000,000 or
greater for the number of nanoseconds results in an error return and
errno is set to EINVAL. The specified time quantum is rounded up by the
system to the next integral multiple of the system clock's resolution.
The maximum time quantum that can be specified is implementation-spe‐
cific and equal to INT_MAX ticks, defined in <limits.h>. Requesting a
quantum greater than this maximum results in an error return and errno
is set to ERANGE. If seconds (RT_KY_TQSECS) but no nanoseconds
(RT_KY_TQNSECS) are supplied, the number of nanoseconds is set to 0. If
nanoseconds (RT_KY_TQNSECS) but no seconds (RT_KY_TQSECS) are supplied,
the number of seconds is set to 0. A time quantum of 0 (seconds and
nanoseconds are 0) results in an error return with errno set to EINVAL.
Special values for RT_KY_TQSECS are RT_TQINF and RT_TQDEF (as described
above). The priocntl() command PC_SETXPARMS knows no special value
RT_NOCHANGE.
To change the class of an LWP to realtime from any other class, the LWP
invoking priocntl() must have sufficient privileges. To change the pri‐
ority or time quantum setting of a realtime LWP, the LWP invoking pri‐
ocntl() must have sufficient privileges or must itself be a realtime
LWP whose real or effective user ID matches the real of effective user
ID of the target LWP.
The realtime priority and time quantum are inherited across fork(2) and
the exec family of functions. When using the time quantum signal with a
user-defined signal handler across the exec functions, the new image
must install an appropriate user-defined signal handler before the time
quantum expires. Otherwise, unpredictable behavior might result.
TIME-SHARING CLASS
The time-sharing scheduling policy provides for a fair and effective
allocation of the CPU resource among LWPs with varying CPU consumption
characteristics. The objectives of the time-sharing policy are to pro‐
vide good response time to interactive LWPs and good throughput to CPU-
bound jobs, while providing a degree of user/application control over
scheduling.
The time-sharing class has a range of time-sharing user priority (see
ts_upri below) values that can be assigned to LWPs within the class. A
ts_upri value of 0 is defined as the default base priority for the
time-sharing class. User priorities range from −x to +x where the value
of x is configurable and can be determined for a specific installation
by using the priocntl() PC_GETCID or PC_GETCLINFO command.
The purpose of the user priority is to provide some degree of user/ap‐
plication control over the scheduling of LWPs in the time-sharing
class. Raising or lowering the ts_upri value of an LWP in the time-
sharing class raises or lowers the scheduling priority of the LWP. It
is not guaranteed, however, that an LWP with a higher ts_upri value
will run before one with a lower ts_upri value, since the ts_upri value
is just one factor used to determine the scheduling priority of a time-
sharing LWP. The system can dynamically adjust the internal scheduling
priority of a time-sharing LWP based on other factors such as recent
CPU usage.
In addition to the system-wide limits on user priority (returned by the
PC_GETCID and PC_GETCLINFO commands) there is a per LWP user priority
limit (see ts_uprilim below) specifying the maximum ts_upri value that
can be set for a given LWP. By default, ts_uprilim is 0.
A tsinfo_t structure with the following members, defined in <sys/tspri‐
ocntl.h>, defines the format used for the attribute data for the time-
sharing class.
short ts_maxupri; /* Limits of user priority range */
The priocntl() PC_GETCID and PC_GETCLINFO commands return time-sharing
class attributes in the pc_clinfo buffer in this format.
The ts_maxupri member specifies the configured maximum user priority
value for the time-sharing class. If ts_maxupri is x, the valid range
for both user priorities and user priority limits is from −x to +x.
A tsparms_t structure with the following members, defined in
<sys/tspriocntl.h>, defines the format used to specify the time-sharing
class-specific scheduling parameters of an LWP.
short ts_uprilim; /* Time-Sharing user priority limit */
short ts_upri; /* Time-Sharing user priority */
When using the priocntl() PC_SETPARMS or PC_GETPARMS commands, if
pc_cid specifies the time-sharing class, the data in the pc_clparms
buffer is in this format.
For the priocntl() PC_GETPARMS command, if pc_cid specifies the time-
sharing class and more than one time-sharing LWP is specified, the
scheduling parameters of the time-sharing LWP with the highest ts_upri
value among the specified LWPs is returned and the LWP ID of this LWP
is returned by the priocntl() call. If there is more than one LWP shar‐
ing the highest user priority, the one returned is implementation-de‐
pendent.
Any time-sharing LWP can lower its own ts_uprilim (or that of another
LWP with the same user ID). Only a time-sharing LWP with sufficient
privileges can raise a ts_uprilim. When changing the class of an LWP to
time-sharing from some other class, sufficient privileges are required
to set the initial ts_uprilim to a value greater than 0. Attempts by an
unprivileged LWP to raise a ts_uprilim or set an initial ts_uprilim
greater than 0 fail with a return value of −1 and errno set to EPERM.
Any time-sharing LWP can set its own ts_upri (or that of another LWP
with the same user ID) to any value less than or equal to the LWP's
ts_uprilim. Attempts to set the ts_upri above the ts_uprilim (and/or
set the ts_uprilim below the ts_upri) result in the ts_upri being set
equal to the ts_uprilim.
Either of the ts_uprilim or ts_upri members can be set to the special
value TS_NOCHANGE, defined in <sys/tspriocntl.h>, to set one of the
values without affecting the other. Specifying TS_NOCHANGE for the
ts_upri when the ts_uprilim is being set to a value below the current
ts_upri causes the ts_upri to be set equal to the ts_uprilim being set.
Specifying TS_NOCHANGE for a parameter when changing the class of an
LWP to time-sharing (from some other class) causes the parameter to be
set to a default value. The default value for the ts_uprilim is 0 and
the default for the ts_upri is to set it equal to the ts_uprilim that
is being set.
When using the priocntl() PC_SETXPARMS or PC_GETXPARMS commands, the
first argument after the command code is the class name of the time-
sharing class (TS). The next arguments are formed as (key, value)
pairs, terminated by a 0 key. The definition for the keys of the time-
sharing class can be found in <sys/tspriocntl.h>. A repeated specifica‐
tion of the same key results in an error return and errno set to EIN‐
VAL.
tab() box; lw(1.44i) |lw(1.08i) |lw(2.98i) lw(1.44i) |lw(1.08i)
|lw(2.98i) KeyValue TypeDescription _ TS_KY_UPRILIMpri_tuser priority
limit _ TS_KY_UPRIpri_tuser priority
When using the priocntl() PC_GETXPARMS command, the value associated
with the key is always a pointer to a scheduling parameter of the value
type in the table above. In contrast, when using the priocntl()
PC_SETXPARMS command, the scheduling parameter is given as a direct
value.
A priocntl() PC_SETXPARMS command with the class name (TS) and without
a following (key, value) pair will set or reset all time-sharing sched‐
uling parameters of the target process(es) to their default values.
Changing the class of an LWP to time-sharing from some other class
causes the parameters to be set to their default values. The default
value for the user priority limit (TS_KY_UPRILIM) is 0. The default
value for the user priority (TS_KY_UPRI) is equal to the user priority
limit (TS_KY_UPRILIM) that is being set.
The priocntl() command PC_SETXPARMS knows no special value TS_NOCHANGE.
The time-sharing user priority and user priority limit are inherited
across fork() and the exec family of functions.
INTERACTIVE CLASS
The interactive scheduling policy is a variation on the time-sharing
scheduling policy. All that can be said about the time-sharing schedul‐
ing policy is also true for the interactive scheduling policy, with one
addition: An LWP in the interactive class with its ia_mode value set to
IA_SET_INTERACTIVE has its time-sharing priority boosted by IA_BOOST
(10).
An iainfo_t structure with the following members, defined in
<sys/iapriocntl.h>, defines the format used for the attribute data for
the interactive class.
short ia_maxupri; /* Limits of user priority range */
The priocntl() PC_GETCID and PC_GETCLINFO commands return interactive
class attributes in the pc_clinfo buffer in this format.
The ia_maxupri member specifies the configured maximum user priority
value for the interactive class. If ia_maxupri is x, the valid range
for both user priorities and user priority limits is from -x to +x.
A iaparms_t structure with the following members, defined in
<sys/iapriocntl.h>, defines the format used to specify the interactive
class-specific scheduling parameters of an LWP.
short ia_uprilim; /* Interactive user priority limit */
short ia_upri; /* Interactive user priority */
int ia_mode; /* interactive on/off */
When using the priocntl() PC_SETPARMS or PC_GETPARMS commands, if
pc_cid specifies the interactive class, the data in the pc_clparms
buffer is in this format.
For the priocntl() PC_GETPARMS command, if pc_cid specifies the inter‐
active class and more than one interactive LWP is specified, the sched‐
uling parameters of the interactive LWP with the highest ia_upri value
among the specified LWPs is returned and the LWP ID of this LWP is re‐
turned by the priocntl() call. If there is more than one LWP sharing
the highest user priority, the one returned is implementation-depen‐
dent.
All that is said above in the TIME-SHARING CLASS section concerning ma‐
nipulation of ts_uprilim and ts_upri applies equally to manipulations
of ia_uprilim and ia_upri in the interactive class.
When using the PC_SETPARMS command, the ia_mode member must be set to
one of the values IA_SET_INTERACTIVE, IA_INTERACTIVE_OFF, or
IA_NOCHANGE, defined in <sys/iapriocntl.h>, to set the interactive mode
on or off or to make no change to the interactive mode.
When using the priocntl() PC_SETXPARMS or PC_GETXPARMS commands, the
first argument after the command code is the class name of the interac‐
tive class (IA). The next arguments are formed as (key, value) pairs,
terminated by a 0 key. The definition for the keys of the interactive
class can be found in <sys/iapriocntl.h>. A repeated specification of
the same key results in an error return and errno set to EINVAL.
tab() box; lw(1.83i) |lw(1.83i) |lw(1.83i) lw(1.83i) |lw(1.83i)
|lw(1.83i) KeyValue TypeDescription _ IA_KY_UPRILIMpri_tuser priority
limit _ IA_KY_UPRIpri_tuser priority _ IA_KY_MODEintinteractive mode
When using the priocntl() PC_GETXPARMS command, the value associated
with the key is always a pointer to a scheduling parameter of the value
type in the table above. In contrast, when using the priocntl()
PC_SETXPARMS command, the scheduling parameter is given as a direct
value.
A priocntl() PC_SETXPARMS command with the class name (IA) and without
a following (key, value) pair will set or reset all interactive sched‐
uling parameters of the target process(es) to their default values.
Changing the class of an LWP to interactive from some other class
causes the parameters to be set to their default values. The default
value for the user priority limit (IA_KY_UPRILIM) is 0. The default
value for the user priority (IA_KY_UPRI) is equal to the user priority
limit (IA_KY_UPRILIM) that is being set. The default value for the in‐
teractive mode (IA_KY_MODE) is IA_SET_INTERACTIVE.
The priocntl() command PC_SETXPARMS knows no special value IA_NOCHANGE.
The interactive user priority and user priority limit are inherited
across fork and the exec family of functions.
FAIR-SHARE CLASS
The fair-share scheduling policy provides a fair allocation of CPU re‐
sources among projects, independent of the number of processes they
contain. Projects are given "shares" to control their quota of CPU re‐
sources. See FSS(4) for more information about how to configure shares.
The fair share class supports the notion of per-LWP user priority (see
fss_upri below) values for compatibility with the time-sharing schedul‐
ing class. An fss_upri value of 0 is defined as the default base prior‐
ity for the fair-share class. User priorities range from -x to +x where
the value of x is configurable and can be determined for a specific in‐
stallation by using the priocntl() PC_GETCID or PC_GETCLINFO command.
The purpose of the user priority is to provide some degree of user/ap‐
plication control over the scheduling of LWPs in the fair-share class.
Raising the fss_upri value of an LWP in the fair-share class tells the
scheduler to give this LWP more CPU time slices, while lowering the
fss_upri value tells the scheduler to give it less CPU slices. It is
not guaranteed, however, that an LWP with a higher fss_upri value will
run before one with a lower fss_upri value. This is because the
fss_upri value is just one factor used to determine the scheduling pri‐
ority of a fair-share LWP. The system can dynamically adjust the inter‐
nal scheduling priority of a fair-share LWP based on other factors such
as recent CPU usage. The fair-share scheduler attempts to provide an
evenly graded effect across the whole range of user priority values.
User priority values do not interfere with project shares. That is,
changing a user priority value of a process does not have any effect on
its project CPU entitlement, which is based on the number of shares it
is allocated in comparison with other projects.
In addition to the system-wide limits on user priority (returned by the
PC_GETCID and PC_GETCLINFO commands), there is a per-LWP user priority
limit (see fss_uprilim below) that specifies the maximum fss_upri value
that can be set for a given LWP. By default, fss_uprilim is 0.
A fssinfo_t structure with the following members, defined in
<sys/fsspriocntl.h>, defines the format used for the attribute data for
the fair-share class.
short fss_maxupri; /* Limits of user priority range */
The priocntl() PC_GETCID and PC_GETCLINFO commands return fair-share
class attributes in the pc_clinfo buffer in this format.
fss_maxupri specifies the configured maximum user priority value for
the fair-share class. If fss_maxupri is x, the valid range for both
user priorities and user priority limits is from -x to +x.
A fssparms_t structure with the following members, defined in
<sys/fsspriocntl.h>, defines the format used to specify the fair-share
class-specific scheduling parameters of an LWP.
short fss_uprilim; /* Fair-share user priority limit */
short fss_upri; /* Fair-share user priority */
When using the priocntl() PC_SETPARMS or PC_GETPARMS commands, if
pc_cid specifies the fair-share class, the data in the pc_clparms
buffer is in this format.
For the priocntl() PC_GETPARMS command, if pc_cid specifies the fair-
share class and more than one fair-share LWP is specified, the schedul‐
ing parameters of the fair-share LWP with the highest fss_upri value
among the specified LWPs is returned and the LWP ID of this LWP is re‐
turned by the priocntl() call. If there is more than one LWP sharing
the highest user priority, the one returned is implementation-depen‐
dent.
Any fair-share LWP can lower its own fss_uprilim (or that of another
LWP with the same user ID). Only a fair-share LWP with sufficient priv‐
ileges can raise an fss_uprilim. When changing the class of an LWP to
fair-share from some other class, sufficient privileges are required to
enter the FSS class or to set the initial fss_uprilim to a value
greater than 0. Attempts by an unprivileged LWP to raise an fss_uprilim
or set an initial fss_uprilim greater than 0 fail with a return value
of -1 and errno set to EPERM.
Any fair-share LWP can set its own fss_upri (or that of another LWP
with the same user ID) to any value less than or equal to the LWP's
fss_uprilim. Attempts to set the fss_upri above the fss_uprilim (and/or
set the fss_uprilim below the fss_upri) result in the fss_upri being
set equal to the fss_uprilim.
Either of the fss_uprilim or fss_upri members can be set to the special
value FSS_NOCHANGE (defined in <sys/fsspriocntl.h>) to set one of the
values without affecting the other. Specifying FSS_NOCHANGE for the
fss_upri when the fss_uprilim is being set to a value below the current
fss_upri causes the fss_upri to be set equal to the fss_uprilim being
set. Specifying FSS_NOCHANGE for a parameter when changing the class of
an LWP to fair-share (from some other class) causes the parameter to be
set to a default value. The default value for the fss_uprilim is 0 and
the default for the fss_upri is to set it equal to the fss_uprilim
which is being set.
The fair-share user priority and user priority limit are inherited
across fork() and the exec family of functions.
FIXED-PRIORITY CLASS
The fixed-priority class provides a fixed-priority preemptive schedul‐
ing policy for those LWPs requiring that the scheduling priorities do
not get dynamically adjusted by the system and that the user/applica‐
tion have control of the scheduling priorities.
The fixed-priority class has a range of fixed-priority user priority
(see fx_upri below) values that can be assigned to LWPs within the
class. A fx_upri value of 0 is defined as the default base priority for
the fixed-priority class. User priorities range from 0 to x where the
value of x is configurable and can be determined for a specific instal‐
lation by using the priocntl() PC_GETCID or PC_GETCLINFO command.
The purpose of the user priority is to provide user/application control
over the scheduling of processes in the fixed-priority class. For
processes in the fixed-priority class, the fx_upri value is, for all
practical purposes, equivalent to the scheduling priority of the
process. The fx_upri value completely determines the scheduling prior‐
ity of a fixed-priority process relative to other processes within its
class. Numerically higher fx_upri values represent higher priorities.
In addition to the system-wide limits on user priority (returned by the
PC_GETCID and PC_GETCLINFO commands), there is a per-LWP user priority
limit (see fx_uprilim below) that specifies the maximum fx_upri value
that can be set for a given LWP. By default, fx_uprilim is 0.
A structure with the following member (defined in <sys/fxpriocntl.h>)
defines the format used for the attribute data for the fixed-priority
class.
pri_t fx_maxupri; /* Maximum user priority */
The priocntl() PC_GETCID and PC_GETCLINFO commands return fixed-prior‐
ity class attributes in the pc_clinfo buffer in this format.
The fx_maxupri member specifies the configured maximum user priority
value for the fixed-priority class. If fx_maxupri is x, the valid range
for both user priorities and user priority limits is from 0 to x.
A structure with the following members (defined in <sys/fxpriocntl.h>)
defines the format used to specify the fixed-priority class-specific
scheduling parameters of an LWP.
pri_t fx_upri; /* Fixed-priority user priority */
pri_t fx_uprilim; /* Fixed-priority user priority limit */
uint_t fx_tqsecs; /* seconds in time quantum */
int fx_tqnsecs; /* additional nanosecs in time quant */
When using the priocntl() PC_SETPARMS or PC_GETPARMS commands, if
pc_cid specifies the fixed-priority class, the data in the pc_clparms
buffer is in this format.
For the priocntl() PC_GETPARMS command, if pc_cid specifies the fixed-
priority class and more than one fixed-priority LWP is specified, the
scheduling parameters of the fixed-priority LWP with the highest
fx_upri value among the specified LWPs is returned and the LWP ID of
this LWP is returned by the priocntl() call. If there is more than one
LWP sharing the highest user priority, the one returned is implementa‐
tion-dependent.
Any fixed-priority LWP can lower its own fx_uprilim (or that of another
LWP with the same user ID). Only a fixed-priority LWP with sufficient
privileges can raise a fx_uprilim. When changing the class of an LWP to
fixed-priority from some other class, sufficient privileges are re‐
quired to set the initial fx_uprilim to a value greater than 0. At‐
tempts by an unprivileged LWP to raise a fx_uprilim or set an initial
fx_uprilim greater than 0 fail with a return value of -1 and errno set
to EPERM.
Any fixed-priority LWP can set its own fx_upri (or that of another LWP
with the same user ID) to any value less than or equal to the LWP's
fx_uprilim. Attempts to set the fx_upri above the fx_uprilim (and/or
set the fx_uprilim below the fx_upri) result in the fx_upri being set
equal to the fx_uprilim.
Either of the fx_uprilim or fx_upri members can be set to the special
value FX_NOCHANGE (defined in <sys/fxpriocntl.h>) to set one of the
values without affecting the other. Specifying FX_NOCHANGE for the
fx_upri when the fx_uprilim is being set to a value below the current
fx_upri causes the fx_upri to be set equal to the fx_uprilim being set.
Specifying FX_NOCHANGE for a parameter when changing the class of an
LWP to fixed-priority (from some other class) causes the parameter to
be set to a default value. The default value for the fx_uprilim is 0
and the default for the fx_upri is to set it equal to the fx_uprilim
that is being set. The default for time quantum is dependent on the
fx_upri and on the system configuration; see fx_dptbl(5).
The fx_tqsecs and fx_tqnsecs members are used for getting or setting
the time quantum associated with an LWP or group of LWPs. fx_tqsecs is
the number of seconds in the time quantum and fx_tqnsecs is the number
of additional nanoseconds in the quantum. For example, setting
fx_tqsecs to 2 and fx_tqnsecs to 500,000,000 (decimal) would result in
a time quantum of two and one-half seconds. Specifying a value of
1,000,000,000 or greater in the fx_tqnsecs member results in an error
return with errno set to EINVAL. Although the resolution of the
tq_nsecs member is very fine, the specified time quantum length is
rounded up by the system to the next integral multiple of the system
clock's resolution. The maximum time quantum that can be specified is
implementation-specific and equal to INT_MAX ticks (defined in <lim‐
its.h>). Requesting a quantum greater than this maximum results in an
error return with errno set to ERANGE, although infinite quantums can
be requested using a special value as explained below. Requesting a
time quantum of 0 (setting both fx_tqsecs and fx_tqnsecs to 0) results
in an error return with errno set to EINVAL.
The fx_tqnsecs member can also be set to one of the following special
values (defined in <sys/fxpriocntl.h>), in which case the value of
fx_tqsecs is ignored:
FX_TQINF Set an infinite time quantum.
FX_TQDEF Set the time quantum to the default for this priority
(see fx_dptbl(5)).
FX_NOCHANGE Do not set the time quantum. This value is useful in
changing the user priority of an LWP without affecting
the time quantum. Specifying this value when changing
the class of an LWP to fixed-priority from some other
class is equivalent to specifying FX_TQDEF.
When using the priocntl() PC_SETXPARMS or PC_GETXPARMS commands, the
first argument after the command code must be the class name of the
fixed-priority class (FX). The next arguments are formed as (key,
value) pairs, terminated by a 0 key. The definition for the keys of the
fixed-priority class can be found in <sys/fxpriocntl.h>. A repeated
specification of the same key results in an error return and errno set
to EINVAL.
tab() box; lw(1.44i) |lw(1.08i) |lw(2.98i) lw(1.44i) |lw(1.08i)
|lw(2.98i) KeyValue TypeDescription _ FX_KY_UPRILIMpri_tuser priority
limit _ FX_KY_UPRIpri_tuser priority _ FX_KY_TQSECSuint_tseconds in
time quantum _ FX_KY_TQNSECSintnanoseconds in time quantum
When using the priocntl() PC_GETXPARMS command, the value associated
with the key is always a pointer to a scheduling parameter of the value
type shown in the table above. In contrast, when using the priocntl()
PC_SETXPARMS command, the scheduling parameter is given as a direct
value.
A priocntl() PC_SETXPARMS command with the class name (FX) and without
a following (key, value) pair will set or reset all realtime scheduling
parameters of the target process(es) to their default values. Changing
the class of an LWP to fixed-priority from some other class causes the
parameters to be set to their default values. The default value for the
user priority limit (FX_KY_UPRILIM) is 0. The default value for the
user priority (FX_KY_UPRI) is equal to the user priority limit
(FX_KY_UPRILIM) that is being set. A default time quantum (FX_TQDEF) is
assigned to each priority class (see fx_dptbl(5)).
The value associated with FX_KY_TQSECS is the number of seconds in the
time quantum. The value associated with FX_KY_TQNSECS is the number of
nanoseconds in the quantum. Specifying a value of 1,000,000,000 or
greater for the number of nanoseconds results in an error return and
errno is set to EINVAL. The specified time quantum is rounded up by the
system to the next integral multiple of the system clock's resolution.
The maximum time quantum that can be specified is implementation-spe‐
cific and equal to INT_MAX ticks, defined in <limits.h>. Requesting a
quantum greater than this maximum results in an error return and errno
is set to ERANGE. If seconds (FX_KY_TQSECS) but no nanoseconds
(FX_KY_TQNSECS) are supplied, the number of nanoseconds is set to 0. If
nanoseconds (FX_KY_TQNSECS) but no seconds (FX_KY_TQSECS) are supplied,
the number of seconds is set to 0. A time quantum of 0 (seconds and
nanoseconds are 0) results in an error return with errno set to EINVAL.
Special values for FX_KY_TQSECS are FX_TQINF and FX_TQDEF (as described
above). The priocntl() command PC_SETXPARMS knows no special value
FX_NOCHANGE.
The fixed-priority user priority and user priority limit are inherited
across fork(2) and the exec family of functions.
RETURN VALUES
Unless otherwise noted above, priocntl() returns 0 on success. On fail‐
ure, priocntl() returns −1 and sets errno to indicate the error.
ERRORS
The priocntl() function will fail if:
EAGAIN An attempt to change the class of an LWP failed because of
insufficient resources other than memory (for example, class-
specific kernel data structures).
EFAULT One of the arguments points to an illegal address.
EINVAL The argument cmd was invalid, an invalid or unconfigured
class was specified, or one of the parameters specified was
invalid.
ENOMEM An attempt to change the class of an LWP failed because of
insufficient memory.
EPERM The {PRIV_PROC_PRIOCNTL} privilege is not asserted in the ef‐
fective set of the calling LWP.
The calling LWP does not have sufficient privileges to affect
the target LWP.
ERANGE The requested time quantum is out of range.
ESRCH None of the specified LWPs exist.
SEE ALSO
priocntl(1), exec(2), fork(2), nice(2), priocntlset(2), FSS(4),
fx_dptbl(5), process(5), rt_dptbl(5), ts_dptbl(5), privileges(7), dis‐
padmin(8), init(8)
HISTORY
The priocntl() function; the TS and RT classes; the P_ALL, P_CID,
P_GID, P_LWPID, P_PGID, P_PID, P_PPID, P_SID, and P_UID id types; and
the PC_ADMIN, PC_GETCID, PC_GETCLINFO, PC_SETPARMS, and PC_GETPARMS
commands have been included in all Sun and Oracle releases of Solaris
since Solaris 2.0.
The IA class was added to Solaris in the Solaris 2.4 release.
The FSS class; the P_PROJID and P_TASKID id types; and the PC_DONICE,
PC_GETXPARMS, and PC_SETXPARMS commands were added to Solaris in the
Solaris 9 release.
The FX class and the P_CTID and P_ZONEID id types were added to Solaris
in the Solaris 10 release.
Oracle Solaris 11.4 27 Apr 2020 priocntl(2)