1priocntl(2) System Calls priocntl(2)
2
6 priocntl - process scheduler control
7
9 #include <sys/types.h>
10 #include <sys/priocntl.h>
11 #include <sys/rtpriocntl.h>
12 #include <sys/tspriocntl.h>
13 #include <sys/iapriocntl.h>
14 #include <sys/fsspriocntl.h>
15 #include <sys/fxpriocntl.h>
16 long priocntl(idtype_t idtype, id_t id, int cmd, /* arg */ ...);
18
21 The priocntl() function provides for control over the scheduling of an
22 active light weight process (LWP).
23 LWPs fall into distinct classes with a separate scheduling policy
26 applied to each class. The classes currently supported are the realtime
27 class, the time-sharing class, the fair-share class, and the fixed-pri‐
28 ority class. The characteristics of these classes are described under
29 the corresponding headings below.
30 The class attribute of an LWP is inherited across the fork(2) function
33 and the exec(2) family of functions. The priocntl() function can be
34 used to dynamically change the class and other scheduling parameters
35 associated with a running LWP or set of LWPs given the appropriate per‐
36 missions as explained below.
37 In the default configuration, a runnable realtime LWP runs before any
40 other LWP. Therefore, inappropriate use of realtime LWP can have a dra‐
41 matic negative impact on system performance.
42 The priocntl() function provides an interface for specifying a process,
45 set of processes, or an LWP to which the function applies. The prioc‐
46 ntlset(2) function provides the same functions as priocntl(), but
47 allows a more general interface for specifying the set of LWPs to which
48 the function is to apply.
49 For priocntl(), the idtype and id arguments are used together to spec‐
52 ify the set of LWPs. The interpretation of id depends on the value of
53 idtype. The possible values for idtype and corresponding interpreta‐
54 tions of id are as follows:
55 P_ALL The priocntl() function applies to all existing LWPs. The
57 value of id is ignored. The permission restrictions
58 described below still apply.
59 P_CID The id argument is a class ID (returned by the priocntl()
62 PC_GETCID command as explained below). The priocntl() func‐
63 tion applies to all LWPs in the specified class.
64 P_GID The id argument is a group ID. The priocntl() function
67 applies to all LWPs with this effective group ID.
68 P_LWPID The id argument is an LWP ID. The priocntl function applies
71 to the LWP with the specified ID within the calling
72 process.
73 P_PGID The id argument is a process group ID. The priocntl() func‐
76 tion applies to all LWPs currently associated with pro‐
77 cesses in the specified process group.
78 P_PID The id argument is a process ID specifying a single
81 process. The priocntl() function applies to all LWPs cur‐
82 rently associated with the specified process.
83 P_PPID The id argument is a parent process ID. The priocntl()
86 function applies to all LWPs currently associated with pro‐
87 cesses with the specified parent process ID.
88 P_PROJID The id argument is a project ID. The priocntl() function
91 applies to all LWPs with this project ID.
92 P_SID The id argument is a session ID. The priocntl() function
95 applies to all LWPs currently associated with processes in
96 the specified session.
97 P_TASKID The id argument is a task ID. The priocntl() function
100 applies to all LWPs currently associated with processes in
101 the specified task.
102 P_UID The id argument is a user ID. The priocntl() function
105 applies to all LWPs with this effective user ID.
106 P_ZONEID The id argument is a zone ID. The priocntl() function
109 applies to all LWPs with this zone ID.
110 P_CTID The id argument is a process contract ID. The priocntl()
113 function applies to all LWPs with this process contract ID.
114 An id value of P_MYID can be used in conjunction with the idtype value
118 to specify the LWP ID, parent process ID, process group ID, session ID,
119 task ID, class ID, user ID, group ID, project ID, zone ID, or process
120 contract ID of the calling LWP.
121 To change the scheduling parameters of an LWP (using the PC_SETPARMS or
124 PC_SETXPARMS command as explained below) , the real or effective user
125 ID of the LWP calling priocntl() must match the real or the calling LWP
126 must have sufficient privileges. These are the minimum permission
127 requirements enforced for all classes. An individual class might impose
128 additional permissions requirements when setting LWPs to that class
129 and/or when setting class-specific scheduling parameters.
130 A special SYS scheduling class exists for the purpose of scheduling the
133 execution of certain special system processes (such as the swapper
134 process). It is not possible to change the class of any LWP to SYS. In
135 addition, any processes in the SYS class that are included in a speci‐
136 fied set of processes are disregarded by priocntl(). For example, an
137 idtype of P_UID and an id value of 0 would specify all processes with a
138 user ID of 0 except processes in the SYS class and (if changing the
139 parameters using PC_SETPARMS or PC_SETXPARMS) the init(1M) process.
140 The init process is a special case. For a priocntl() call to change the
143 class or other scheduling parameters of the init process (process ID
144 1), it must be the only process specified by idtype and id. The init
145 process can be assigned to any class configured on the system, but the
146 time-sharing class is almost always the appropriate choice. (Other
147 choices might be highly undesirable. See the System Administration
148 Guide: Basic Administration for more information.)
149 The data type and value of arg are specific to the type of command
152 specified by cmd.
153 A pcinfo_t structure with the following members, defined in <sys/prioc‐
156 ntl.h>, is used by the PC_GETCID and PC_GETCLINFO commands.
157 id_t pc_cid; /* Class id */
159 char pc_clname[PC_CLNMSZ]; /* Class name */
160 int pc_clinfo[PC_CLINFOSZ]; /* Class information */
161 The pc_cid member is a class ID returned by the priocntl() PC_GETCID
165 command.
166 The pc_clname member is a buffer of size PC_CLNMSZ, defined in
169 <sys/priocntl.h>, used to hold the class name: RT for realtime, TS for
170 time-sharing, IAfor interactive, FSS for fair-share, or FX for fixed-
171 priority. Each string is null-terminated.
172 The pc_clinfo member is a buffer of size PC_CLINFOSZ, defined in
175 <sys/priocntl.h>, used to return data describing the attributes of a
176 specific class. The format of this data is class-specific and is
177 described under the appropriate heading (REALTIME CLASS, TIME-SHARING
178 CLASS, INTERACTIVE CLASS, FAIR-SHARE CLASS, or FIXED-PRIORITY CLASS)
179 below.
180 A pcparms_t structure with the following members, defined in <sys/pri‐
183 ocntl.h>, is used by the PC_SETPARMS and PC_GETPARMS commands.
184 id_t pc_cid; /* LWP class */
186 int pc_clparms[PC_CLPARMSZ]; /* Class-specific params */
187 The pc_cid member is a class ID returned by the priocntl() PC_GETCID
191 command. The special class ID PC_CLNULL can also be assigned to pc_cid
192 when using the PC_GETPARMS command as explained below.
193 The pc_clparms buffer holds class-specific scheduling parameters. The
196 format of this parameter data for a particular class is described under
197 the appropriate heading below. PC_CLPARMSZ is the length of the
198 pc_clparms buffer and is defined in <sys/priocntl.h>.
199 The PC_SETXPARMS and PC_GETXPARMS commands exploit the varargs declara‐
202 tion of priocntl(). The argument following the command code is a class
203 name: RT for realtime, TS for time-sharing, IA for interactive, FSS for
204 fair-share, or FX for fixed-priority. The parameters after the class
205 name build a chain of (key, value) pairs, where the key determines the
206 meaning of the value within the pair. When using PC_GETXPARMS, the
207 value associated with the key is always a pointer to a scheduling
208 parameter. In contrast, when using PC_SETXPARMS the scheduling parame‐
209 ter is given as a direct value. A key value of 0 terminates the
210 sequence and all further keys or values are ignored.
211 The PC_SETXPARMS and PC_GETXPARMS commands are more flexible than
214 PC_SETPARMS and PC_GETPARMS and should replace PC_SETPARMS and PC_GET‐
215 PARMS on a long-term basis.
216
218 Available priocntl() commands are:
219 PC_ADMIN This command provides functionality needed for the
221 implementation of the dispadmin(1M) utility. It is not
222 intended for general use by other applications.
223 PC_DONICE Set or get nice value of the specified LWP(s) associ‐
226 ated with the specified process(es). When this command
227 is used with the idtype of P_LWPID, it sets the nice
228 value of the LWP. The arg argument points to a struc‐
229 ture of type pcnice_t. The pc_val member specifies the
230 nice value and the pc_op specifies the type of the
231 operation.
232 When pc_op is set to PC_GETNICE, priocntl() sets the
234 pc_val to the highest priority (lowest numerical value)
235 pertaining to any of the specified LWPs.
236 When pc_op is set to PC_SETNICE, priocntl() sets the
238 nice value of all LWPs in the specified set to the
239 value specified in pc_val member of pcnice_t structure.
240 The priocntl() function returns −1 with errno set to
242 EPERM if the calling LWP doesn't have appropriate per‐
243 missions to set or get nice values for one or more of
244 the target LWPs. If priocntl() encounters an error
245 other than permissions, it does not continue through
246 the set of target LWPs but returns the error immedi‐
247 ately.
248 PC_GETCID Get class ID and class attributes for a specific class
251 given the class name. The idtype and id arguments are
252 ignored. If arg is non-null, it points to a structure
253 of type pcinfo_t. The pc_clname buffer contains the
254 name of the class whose attributes you are getting.
255 On success, the class ID is returned in pc_cid, the
257 class attributes are returned in the pc_clinfo buffer,
258 and the priocntl() call returns the total number of
259 classes configured in the system (including the sys
260 class). If the class specified by pc_clname is invalid
261 or is not currently configured, the priocntl() call
262 returns −1 with errno set to EINVAL. The format of the
263 attribute data returned for a given class is defined in
264 the <sys/rtpriocntl.h>, <sys/tspriocntl.h>, <sys/iapri‐
265 ocntl.h>, <sys/fsspriocntl.h>, or <sys/fxpriocntl.h>
266 header and described under the appropriate heading
267 below.
268 If arg is a null pointer, no attribute data is returned
270 but the priocntl() call still returns the number of
271 configured classes.
272 PC_GETCLINFO Get class name and class attributes for a specific
275 class given class ID. The idtype and id arguments are
276 ignored. If arg is non-null, it points to a structure
277 of type pcinfo_t. The pc_cid member is the class ID of
278 the class whose attributes you are getting.
279 On success, the class name is returned in the pc_clname
281 buffer, the class attributes are returned in the
282 pc_clinfo buffer, and the priocntl() call returns the
283 total number of classes configured in the system
284 (including the sys class). The format of the attribute
285 data returned for a given class is defined in the
286 <sys/rtpriocntl.h>, <sys/tspriocntl.h>, <sys/iaprioc‐
287 ntl.h>, <sys/fsspriocntl.h>, or <sys/fxpriocntl.h>
288 header and described under the appropriate heading
289 below.
290 If arg is a null pointer, no attribute data is returned
292 but the priocntl() call still returns the number of
293 configured classes.
294 PC_GETPARMS Get the class and/or class-specific scheduling parame‐
297 ters of an LWP. The arg member points to a structure of
298 type pcparms_t.
299 If pc_cid specifies a configured class and a single LWP
301 belonging to that class is specified by the idtype and
302 id values or the procset structure, then the scheduling
303 parameters of that LWP are returned in the pc_clparms
304 buffer. If the LWP specified does not exist or does not
305 belong to the specified class, the priocntl() call
306 returns −1 with errno set to ESRCH.
307 If pc_cid specifies a configured class and a set of
309 LWPs is specified, the scheduling parameters of one of
310 the specified LWP belonging to the specified class are
311 returned in the pc_clparms buffer and the priocntl()
312 call returns the process ID of the selected LWP. The
313 criteria for selecting an LWP to return in this case is
314 class-dependent. If none of the specified LWPs exist or
315 none of them belong to the specified class, the prioc‐
316 ntl() call returns −1 with errno set to ESRCH.
317 If pc_cid is PC_CLNULL and a single LWP is specified,
319 the class of the specified LWP is returned in pc_cid
320 and its scheduling parameters are returned in the
321 pc_clparms buffer.
322 PC_GETXPARMS Get the class or class-specific scheduling parameters
325 of an LWP. The class name (first argument after
326 PC_GETXPARMS) specifies the class and the (key, value)
327 pair sequence contains a pointer to the class-specific
328 parameters. The keys and the types of the class-spe‐
329 cific parameter data are described below and can also
330 be found in the class-specific headers <sys/rtprioc‐
331 ntl.h>, <sys/tspriocntl.h>, <sys/iapriocntl.h>,
332 <sys/fsspriocntl.h>, and <sys/fxpriocntl.h>. If the
333 specified class is a configured class and a single LWP
334 belonging to that class is specified by the idtype and
335 id values or the procset structure, then the scheduling
336 parameters of that LWP are returned in the given (key,
337 value) pair buffers. If the LWP specified does not
338 exist or does not belong to the specified class, prioc‐
339 ntl() returns −1 and errno is set to ESRCH.
340 If the class name specifies a configured class and a
342 set of LWPs is given, the scheduling parameters of one
343 of the specified LWPs belonging to the specified class
344 are returned and the priocntl() call returns the
345 process ID of the selected LWP. The criteria for
346 selecting an LWP to return in this case is class-depen‐
347 dent. If none of the specified LWPs exist or none of
348 them belong to the specified class, priocntl() returns
349 −1 and errno is set to ESRCH.
350 If the class name is a null pointer, a single process
352 or LWP is specified, and a (key, value) pair for a
353 class name request is given, priocntl() fills the buf‐
354 fer pointed to by value with the class name of the
355 specified process or LWP. The key for the class name
356 request is PC_KY_CLNAME and the class name buffer
357 should be declared as:
358 char pc_clname[PC_CLNMSZ]; /* Class name */
360 PC_SETPARMS Set the class and class-specific scheduling parameters
364 of the specified LWP(s) associated with the specified
365 process(es). When this command is used with the idtype
366 of P_LWPID, it will set the class and class-specific
367 scheduling parameters of the LWP. The arg argument
368 points to a structure of type pcparms_t. The pc_cid
369 member specifies the class you are setting and the
370 pc_clparms buffer contains the class-specific parame‐
371 ters you are setting. The format of the class-specific
372 parameter data is defined in the <sys/rtpriocntl.h>,
373 <sys/tspriocntl.h>, <sys/iapriocntl.h>, <sys/fssprioc‐
374 ntl.h>, or <sys/fxpriocntl.h> header and described
375 under the appropriate class heading below.
376 When setting parameters for a set of LWPs, priocntl()
378 acts on the LWPs in the set in an implementation-spe‐
379 cific order. If priocntl() encounters an error for one
380 or more of the target processes, it might or might not
381 continue through the set of LWPs, depending on the
382 nature of the error. If the error is related to permis‐
383 sions (EPERM), priocntl() continues through the LWP
384 set, resetting the parameters for all target LWPs for
385 which the calling LWP has appropriate permissions. The
386 priocntl() function then returns −1 with errno set to
387 EPERM to indicate that the operation failed for one or
388 more of the target LWPs. If priocntl() encounters an
389 error other than permissions, it does not continue
390 through the set of target LWPs but returns the error
391 immediately.
392 PC_SETXPARMS Set the class and class-specific scheduling parameters
395 of the specified LWP(s) associated with the specified
396 process(es). When this command is used with P_LWPID as
397 idtype, it will set the class and class-specific sched‐
398 uling parameters of the LWP. The class name (first
399 argument after PC_SETXPARMS) specifies the class to be
400 changed and the following (key, value) pair sequence
401 contains the class-specific parameters to be changed.
402 Only those (key,value) pairs whose scheduling behavior
403 is to change must be specified. The keys and the types
404 of the class-specific parameter data are described
405 below and can also be found in the class-specific
406 header files <sys/rtpriocntl.h>, <sys/tspriocntl.h>,
407 <sys/iapriocntl.h>, <sys/fsspriocntl.h>, and
408 <sys/fxpriocntl.h>.
409 When setting parameters for a set of LWPs, priocntl()
411 acts on the LWPs in the set in an implementation-spe‐
412 cific order. If priocntl() encounters an error for one
413 or more of the target processes, it might or might not
414 continue through the set of LWPs, depending on the
415 nature of the error. If the error is related to permis‐
416 sions (EPERM), priocntl() continues to reset the param‐
417 eters for all target LWPs where the calling LWP has
418 appropriate permissions. The priocntl() function
419 returns −1 and errno is set to EPERM when the operation
420 failed for one or more of the target LWPs. All errors
421 other than EPERM result in an immediate termination of
422 priocntl().
423
426 The realtime class provides a fixed priority preemptive scheduling pol‐
427 icy for those LWPS requiring fast and deterministic response and abso‐
428 lute user/application control of scheduling priorities. If the realtime
429 class is configured in the system, it should have exclusive control of
430 the highest range of scheduling priorities on the system. This ensures
431 that a runnable realtime LWP is given CPU service before any LWP
432 belonging to any other class.
433 The realtime class has a range of realtime priority (rt_pri) values
436 that can be assigned to an LWP within the class. Realtime priorities
437 range from 0 to x, where the value of x is configurable and can be
438 determined for a specific installation by using the priocntl() PC_GET‐
439 CID or PC_GETCLINFO command.
440 The realtime scheduling policy is a fixed priority policy. The schedul‐
443 ing priority of a realtime LWP is never changed except as the result of
444 an explicit request by the user/application to change the rt_pri value
445 of the LWP.
446 For an LWP in the realtime class, the rt_pri value is, for all practi‐
449 cal purposes, equivalent to the scheduling priority of the LWP. The
450 rt_pri value completely determines the scheduling priority of a real‐
451 time LWP relative to other LWPs within its class. Numerically higher
452 rt_pri values represent higher priorities. Since the realtime class
453 controls the highest range of scheduling priorities in the system, it
454 is guaranteed that the runnable realtime LWP with the highest rt_pri
455 value is always selected to run before any other LWPs in the system.
456 In addition to providing control over priority, priocntl() provides for
459 control over the length of the time quantum allotted to the LWP in the
460 realtime class. The time quantum value specifies the maximum amount of
461 time an LWP can run assuming that it does not complete or enter a
462 resource or event wait state (sleep). If another LWP becomes runnable
463 at a higher priority, the currently running LWP might be preempted
464 before receiving its full time quantum.
465 The realtime quantum signal can be used for the notification of runaway
468 realtime processes about the consumption of their time quantum. Those
469 processes, which are monitored by the realtime time quantum signal,
470 receive the configured signal in the event of time quantum expiration.
471 The default value (0) of the time quantum signal will denote no signal
472 delivery and a positive value will denote the delivery of the signal
473 specified by the value. The realtime quantum signal can be set with the
474 priocntl() PC_SETXPARMS command and displayed with the priocntl()
475 PC_GETXPARMS command as explained below.
476 The system's process scheduler keeps the runnable realtime LWPs on a
479 set of scheduling queues. There is a separate queue for each configured
480 realtime priority and all realtime LWPs with a given rt_pri value are
481 kept together on the appropriate queue. The LWPs on a given queue are
482 ordered in FIFO order (that is, the LWP at the front of the queue has
483 been waiting longest for service and receives the CPU first). Realtime
484 LWPs that wake up after sleeping, LWPs that change to the realtime
485 class from some other class, LWPs that have used their full time quan‐
486 tum, and runnable LWPs whose priority is reset by priocntl() are all
487 placed at the back of the appropriate queue for their priority. An LWP
488 that is preempted by a higher priority LWP remains at the front of the
489 queue (with whatever time is remaining in its time quantum) and runs
490 before any other LWP at this priority. Following a fork(2) function
491 call by a realtime LWP, the parent LWP continues to run while the child
492 LWP (which inherits its parent's rt_pri value) is placed at the back of
493 the queue.
494 A rtinfo_t structure with the following members, defined in <sys/rtpri‐
497 ocntl.h>, defines the format used for the attribute data for the real‐
498 time class.
499 short rt_maxpri; /* Maximum realtime priority */
501 The priocntl() PC_GETCID and PC_GETCLINFO commands return realtime
505 class attributes in the pc_clinfo buffer in this format.
506 The rt_maxpri member specifies the configured maximum rt_pri value for
509 the realtime class. If rt_maxpri is x, the valid realtime priorities
510 range from 0 to x.
511 A rtparms_t structure with the following members, defined in
514 <sys/rtpriocntl.h>, defines the format used to specify the realtime
515 class-specific scheduling parameters of an LWP.
516 short rt_pri; /* Real-Time priority */
518 uint_t rt_tqsecs; /* Seconds in time quantum */
519 int rt_tqnsecs; /* Additional nanoseconds in quantum */
520 When using the priocntl() PC_SETPARMS or PC_GETPARMS commands, if
524 pc_cid specifies the realtime class, the data in the pc_clparms buffer
525 are in this format.
526 These commands can be used to set the realtime priority to the speci‐
529 fied value or get the current rt_pri value. Setting the rt_pri value of
530 an LWP that is currently running or runnable (not sleeping) causes the
531 LWP to be placed at the back of the scheduling queue for the specified
532 priority. The LWP is placed at the back of the appropriate queue
533 regardless of whether the priority being set is different from the pre‐
534 vious rt_pri value of the LWP. A running LWP can voluntarily release
535 the CPU and go to the back of the scheduling queue at the same priority
536 by resetting its rt_pri value to its current realtime priority value.
537 To change the time quantum of an LWP without setting the priority or
538 affecting the LWP's position on the queue, the rt_pri member should be
539 set to the special value RT_NOCHANGE, defined in <sys/rtpriocntl.h>.
540 Specifying RT_NOCHANGE when changing the class of an LWP to realtime
541 from some other class results in the realtime priority being set to 0.
542 For the priocntl() PC_GETPARMS command, if pc_cid specifies the real‐
545 time class and more than one realtime LWP is specified, the scheduling
546 parameters of the realtime LWP with the highest rt_pri value among the
547 specified LWPs are returned and the LWP ID of this LWP is returned by
548 the priocntl() call. If there is more than one LWP sharing the highest
549 priority, the one returned is implementation-dependent.
550 The rt_tqsecs and rt_tqnsecs members are used for getting or setting
553 the time quantum associated with an LWP or group of LWPs. rt_tqsecs is
554 the number of seconds in the time quantum and rt_tqnsecs is the number
555 of additional nanoseconds in the quantum. For example, setting
556 rt_tqsecs to 2 and rt_tqnsecs to 500,000,000 (decimal) would result in
557 a time quantum of two and one-half seconds. Specifying a value of
558 1,000,000,000 or greater in the rt_tqnsecs member results in an error
559 return with errno set to EINVAL. Although the resolution of the
560 tq_nsecs member is very fine, the specified time quantum length is
561 rounded up by the system to the next integral multiple of the system
562 clock's resolution. The maximum time quantum that can be specified is
563 implementation-specific and equal to INT_MAX1 ticks. The INT_MAX value
564 is defined in <limits.h>. Requesting a quantum greater than this maxi‐
565 mum results in an error return with errno set to ERANGE, although infi‐
566 nite quantums can be requested using a special value as explained
567 below. Requesting a time quantum of 0 by setting both rt_tqsecs and
568 rt_tqnsecs to 0 results in an error return with errno set to EINVAL.
569 The rt_tqnsecs member can also be set to one of the following special
572 values defined in <sys/rtpriocntl.h>, in which case the value of
573 rt_tqsecs is ignored:
574 RT_TQINF Set an infinite time quantum.
576 RT_TQDEF Set the time quantum to the default for this priority
579 (see rt_dptbl(4)).
580 RT_NOCHANGE Do not set the time quantum. This value is useful when
583 you wish to change the realtime priority of an LWP with‐
584 out affecting the time quantum. Specifying this value
585 when changing the class of an LWP to realtime from some
586 other class is equivalent to specifying RT_TQDEF.
587 When using the priocntl() PC_SETXPARMS or PC_GETXPARMS commands, the
591 first argument after the command code must be the class name of the
592 realtime class (RT) . The next arguments are formed as (key, value)
593 pairs, terminated by a 0 key. The definition for the keys of the real‐
594 time class can be found in <sys/rtpriocntl.h>. A repeated specification
595 of the same key results in an error return and errno set to EINVAL.
596 ┌────────────────┬─────────────┬───────────────────────────────┐
601 │ Key │Value Type │ Description │
602 ├────────────────┼─────────────┼───────────────────────────────┤
603 │RT_KY_PRI │pri_t │realtime priority │
604 │RT_KY_TQSECS │uint_t │seconds in time quantum │
605 ├────────────────┼─────────────┼───────────────────────────────┤
606 │RT_KY_TQNSECS │int │nanoseconds in time quantum │
607 ├────────────────┼─────────────┼───────────────────────────────┤
608 │RT_KY_TQSIG │int │realtime time quantum signal │
609 └────────────────┴─────────────┴───────────────────────────────┘
610 When using the priocntl() PC_GETXPARMS command, the value associated
613 with the key is always a pointer to a scheduling parameter of the value
614 type shown in the table above. In contrast, when using the priocntl()
615 PC_SETXPARMS command, the scheduling parameter is given as a direct
616 value.
617 A priocntl() PC_SETXPARMS command with the class name (RT) and without
620 a following (key, value) pair will set or reset all realtime scheduling
621 parameters of the target process(es) to their default values. Changing
622 the class of an LWP to realtime from some other class causes the param‐
623 eters to be set to their default values. The default realtime priority
624 (RT_KY_PRI) is 0. A default time quantum (RT_TQDEF) is assigned to each
625 priority class (see rt_dptbl(4)). The default realtime time quantum
626 signal (RT_KY_TQSIG) is 0.
627 The value associated with RT_KY_TQSECS is the number of seconds in the
630 time quantum. The value associated with RT_KY_TQNSECS is the number of
631 nanoseconds in the quantum. Specifying a value of 1,000,000,000 or
632 greater for the number of nanoseconds results in an error return and
633 errno is set to EINVAL. The specified time quantum is rounded up by the
634 system to the next integral multiple of the system clock's resolution.
635 The maximum time quantum that can be specified is implementation-spe‐
636 cific and equal to INT_MAX ticks, defined in <limits.h>. Requesting a
637 quantum greater than this maximum results in an error return and errno
638 is set to ERANGE. If seconds (RT_KY_TQSECS) but no nanoseconds
639 (RT_KY_TQNSECS) are supplied, the number of nanoseconds is set to 0. If
640 nanoseconds (RT_KY_TQNSECS) but no seconds (RT_KY_TQSECS) are supplied,
641 the number of seconds is set to 0. A time quantum of 0 (seconds and
642 nanoseconds are 0) results in an error return with errno set to EINVAL.
643 Special values for RT_KY_TQSECS are RT_TQINF and RT_TQDEF (as described
644 above). The priocntl() command PC_SETXPARMS knows no special value
645 RT_NOCHANGE.
646 To change the class of an LWP to realtime from any other class, the LWP
649 invoking priocntl() must have sufficient privileges. To change the pri‐
650 ority or time quantum setting of a realtime LWP, the LWP invoking pri‐
651 ocntl() must have sufficient privileges or must itself be a realtime
652 LWP whose real or effective user ID matches the real of effective user
653 ID of the target LWP.
654 The realtime priority and time quantum are inherited across fork(2) and
657 the exec family of functions. When using the time quantum signal with a
658 user-defined signal handler across the exec functions, the new image
659 must install an appropriate user-defined signal handler before the time
660 quantum expires. Otherwise, unpredictable behavior might result.
661
663 The time-sharing scheduling policy provides for a fair and effective
664 allocation of the CPU resource among LWPs with varying CPU consumption
665 characteristics. The objectives of the time-sharing policy are to pro‐
666 vide good response time to interactive LWPs and good throughput to CPU-
667 bound jobs, while providing a degree of user/application control over
668 scheduling.
669 The time-sharing class has a range of time-sharing user priority (see
672 ts_upri below) values that can be assigned to LWPs within the class. A
673 ts_upri value of 0 is defined as the default base priority for the
674 time-sharing class. User priorities range from −x to +x where the value
675 of x is configurable and can be determined for a specific installation
676 by using the priocntl() PC_GETCID or PC_GETCLINFO command.
677 The purpose of the user priority is to provide some degree of
680 user/application control over the scheduling of LWPs in the time-shar‐
681 ing class. Raising or lowering the ts_upri value of an LWP in the time-
682 sharing class raises or lowers the scheduling priority of the LWP. It
683 is not guaranteed, however, that an LWP with a higher ts_upri value
684 will run before one with a lower ts_upri value, since the ts_upri value
685 is just one factor used to determine the scheduling priority of a time-
686 sharing LWP. The system can dynamically adjust the internal scheduling
687 priority of a time-sharing LWP based on other factors such as recent
688 CPU usage.
689 In addition to the system-wide limits on user priority (returned by the
692 PC_GETCID and PC_GETCLINFO commands) there is a per LWP user priority
693 limit (see ts_uprilim below) specifying the maximum ts_upri value that
694 can be set for a given LWP. By default, ts_uprilim is 0.
695 A tsinfo_t structure with the following members, defined in <sys/tspri‐
698 ocntl.h>, defines the format used for the attribute data for the time-
699 sharing class.
700 short ts_maxupri; /* Limits of user priority range */
702 The priocntl() PC_GETCID and PC_GETCLINFO commands return time-sharing
706 class attributes in the pc_clinfo buffer in this format.
707 The ts_maxupri member specifies the configured maximum user priority
710 value for the time-sharing class. If ts_maxupri is x, the valid range
711 for both user priorities and user priority limits is from −x to +x.
712 A tsparms_t structure with the following members, defined in
715 <sys/tspriocntl.h>, defines the format used to specify the time-sharing
716 class-specific scheduling parameters of an LWP.
717 short ts_uprilim; /* Time-Sharing user priority limit */
719 short ts_upri; /* Time-Sharing user priority */
720 When using the priocntl() PC_SETPARMS or PC_GETPARMS commands, if
724 pc_cid specifies the time-sharing class, the data in the pc_clparms
725 buffer is in this format.
726 For the priocntl() PC_GETPARMS command, if pc_cid specifies the time-
729 sharing class and more than one time-sharing LWP is specified, the
730 scheduling parameters of the time-sharing LWP with the highest ts_upri
731 value among the specified LWPs is returned and the LWP ID of this LWP
732 is returned by the priocntl() call. If there is more than one LWP shar‐
733 ing the highest user priority, the one returned is implementation-
734 dependent.
735 Any time-sharing LWP can lower its own ts_uprilim (or that of another
738 LWP with the same user ID). Only a time-sharing LWP with sufficient
739 privileges can raise a ts_uprilim. When changing the class of an LWP to
740 time-sharing from some other class, sufficient privileges are required
741 to set the initial ts_uprilim to a value greater than 0. Attempts by an
742 unprivileged LWP to raise a ts_uprilim or set an initial ts_uprilim
743 greater than 0 fail with a return value of −1 and errno set to EPERM.
744 Any time-sharing LWP can set its own ts_upri (or that of another LWP
747 with the same user ID) to any value less than or equal to the LWP's
748 ts_uprilim. Attempts to set the ts_upri above the ts_uprilim (and/or
749 set the ts_uprilim below the ts_upri) result in the ts_upri being set
750 equal to the ts_uprilim.
751 Either of the ts_uprilim or ts_upri members can be set to the special
754 value TS_NOCHANGE, defined in <sys/tspriocntl.h>, to set one of the
755 values without affecting the other. Specifying TS_NOCHANGE for the
756 ts_upri when the ts_uprilim is being set to a value below the current
757 ts_upri causes the ts_upri to be set equal to the ts_uprilim being set.
758 Specifying TS_NOCHANGE for a parameter when changing the class of an
759 LWP to time-sharing (from some other class) causes the parameter to be
760 set to a default value. The default value for the ts_uprilim is 0 and
761 the default for the ts_upri is to set it equal to the ts_uprilim that
762 is being set.
763 When using the priocntl() PC_SETXPARMS or PC_GETXPARMS commands, the
766 first argument after the command code is the class name of the time-
767 sharing class (TS) . The next arguments are formed as (key, value)
768 pairs, terminated by a 0 key. The definition for the keys of the time-
769 sharing class can be found in <sys/tspriocntl.h>. A repeated specifi‐
770 cation of the same key results in an error return and errno set to EIN‐
771 VAL.
772 ┌────────────────┬─────────────┬───────────────────────────────┐
777 │ Key │Value Type │ Description │
778 ├────────────────┼─────────────┼───────────────────────────────┤
779 │TS_KY_UPRILIM │pri_t │user priority limit │
780 │TS_KY_UPRI │pri_t │user priority │
781 └────────────────┴─────────────┴───────────────────────────────┘
782 When using the priocntl() PC_GETXPARMS command, the value associated
785 with the key is always a pointer to a scheduling parameter of the value
786 type in the table above. In contrast, when using the priocntl()
787 PC_SETXPARMS command, the scheduling parameter is given as a direct
788 value.
789 A priocntl() PC_SETXPARMS command with the class name (TS) and without
792 a following (key, value) pair will set or reset all time-sharing sched‐
793 uling parameters of the target process(es) to their default values.
794 Changing the class of an LWP to time-sharing from some other class
795 causes the parameters to be set to their default values. The default
796 value for the user priority limit (TS_KY_UPRILIM) is 0. The default
797 value for the user priority (TS_KY_UPRI) is equal to the user priority
798 limit (TS_KY_UPRILIM) that is being set.
799 The priocntl() command PC_SETXPARMS knows no special value TS_NOCHANGE.
802 The time-sharing user priority and user priority limit are inherited
805 across fork() and the exec family of functions.
806
808 The interactive scheduling policy is a variation on the time-sharing
809 scheduling policy. All that can be said about the time-sharing schedul‐
810 ing policy is also true for the interactive scheduling policy, with one
811 addition: An LWP in the interactive class with its ia_mode value set to
812 IA_SET_INTERACTIVE has its time-sharing priority boosted by IA_BOOST
813 (10).
814 An iainfo_t structure with the following members, defined in
817 <sys/iapriocntl.h>, defines the format used for the attribute data for
818 the interactive class.
819 short ia_maxupri; /* Limits of user priority range */
821 The priocntl() PC_GETCID and PC_GETCLINFO commands return interactive
825 class attributes in the pc_clinfo buffer in this format.
826 The ia_maxupri member specifies the configured maximum user priority
829 value for the interactive class. If ia_maxupri is x, the valid range
830 for both user priorities and user priority limits is from -x to +x.
831 A iaparms_t structure with the following members, defined in
834 <sys/iapriocntl.h>, defines the format used to specify the interactive
835 class-specific scheduling parameters of an LWP.
836 short ia_uprilim; /* Interactive user priority limit */
838 short ia_upri; /* Interactive user priority */
839 int ia_mode; /* interactive on/off */
840 When using the priocntl() PC_SETPARMS or PC_GETPARMS commands, if
844 pc_cid specifies the interactive class, the data in the pc_clparms buf‐
845 fer is in this format.
846 For the priocntl() PC_GETPARMS command, if pc_cid specifies the inter‐
849 active class and more than one interactive LWP is specified, the sched‐
850 uling parameters of the interactive LWP with the highest ia_upri value
851 among the specified LWPs is returned and the LWP ID of this LWP is
852 returned by the priocntl() call. If there is more than one LWP sharing
853 the highest user priority, the one returned is implementation-depen‐
854 dent.
855 All that is said above in the TIME-SHARING CLASS section concerning
858 manipulation of ts_uprilim and ts_upri applies equally to manipulations
859 of ia_uprilim and ia_upri in the interactive class.
860 When using the PC_SETPARMS command, the ia_mode member must be set to
863 one of the values IA_SET_INTERACTIVE, IA_INTERACTIVE_OFF, or
864 IA_NOCHANGE, defined in <sys/iapriocntl.h>, to set the interactive mode
865 on or off or to make no change to the interactive mode.
866 When using the priocntl() PC_SETXPARMS or PC_GETXPARMS commands, the
869 first argument after the command code is the class name of the interac‐
870 tive class (IA) . The next arguments are formed as (key, value) pairs,
871 terminated by a 0 key. The definition for the keys of the interactive
872 class can be found in <sys/iapriocntl.h>. A repeated specification of
873 the same key results in an error return and errno set to EINVAL.
874 Key Value Type Description
879 IA_KY_UPRILIM pri_t user priority limit
880 IA_KY_UPRI pri_t user priority
881 IA_KY_MODE int interactive mode
882 When using the priocntl() PC_GETXPARMS command, the value associated
886 with the key is always a pointer to a scheduling parameter of the value
887 type in the table above. In contrast, when using the priocntl()
888 PC_SETXPARMS command, the scheduling parameter is given as a direct
889 value.
890 A priocntl() PC_SETXPARMS command with the class name (IA) and without
893 a following (key, value) pair will set or reset all interactive sched‐
894 uling parameters of the target process(es) to their default values.
895 Changing the class of an LWP to interactive from some other class
896 causes the parameters to be set to their default values. The default
897 value for the user priority limit (IA_KY_UPRILIM) is 0. The default
898 value for the user priority (IA_KY_UPRI) is equal to the user priority
899 limit (IA_KY_UPRILIM) that is being set. The default value for the
900 interactive mode (IA_KY_MODE) is IA_SET_INTERACTIVE.
901 The priocntl() command PC_SETXPARMS knows no special value IA_NOCHANGE.
904 The interactive user priority and user priority limit are inherited
907 across fork and the exec family of functions.
908
910 The fair-share scheduling policy provides a fair allocation of CPU
911 resources among projects, independent of the number of processes they
912 contain. Projects are given "shares" to control their quota of CPU
913 resources. See FSS(7) for more information about how to configure
914 shares.
915 The fair share class supports the notion of per-LWP user priority (see
918 fss_upri below) values for compatibility with the time-sharing schedul‐
919 ing class. An fss_upri value of 0 is defined as the default base prior‐
920 ity for the fair-share class. User priorities range from -x to +x where
921 the value of x is configurable and can be determined for a specific
922 installation by using the priocntl() PC_GETCID or PC_GETCLINFO command.
923 The purpose of the user priority is to provide some degree of
926 user/application control over the scheduling of LWPs in the fair-share
927 class. Raising the fss_upri value of an LWP in the fair-share class
928 tells the scheduler to give this LWP more CPU time slices, while lower‐
929 ing the fss_upri value tells the scheduler to give it less CPU slices.
930 It is not guaranteed, however, that an LWP with a higher fss_upri value
931 will run before one with a lower fss_upri value. This is because the
932 fss_upri value is just one factor used to determine the scheduling pri‐
933 ority of a fair-share LWP. The system can dynamically adjust the inter‐
934 nal scheduling priority of a fair-share LWP based on other factors such
935 as recent CPU usage. The fair-share scheduler attempts to provide an
936 evenly graded effect across the whole range of user priority values.
937 User priority values do not interfere with project shares. That is,
940 changing a user priority value of a process does not have any effect on
941 its project CPU entitlement, which is based on the number of shares it
942 is allocated in comparison with other projects.
943 In addition to the system-wide limits on user priority (returned by the
946 PC_GETCID and PC_GETCLINFO commands), there is a per-LWP user priority
947 limit (see fss_uprilim below) that specifies the maximum fss_upri value
948 that can be set for a given LWP. By default, fss_uprilim is 0.
949 A fssinfo_t structure with the following members, defined in
952 <sys/fsspriocntl.h>, defines the format used for the attribute data
953 for the fair-share class.
954 short fss_maxupri; /* Limits of user priority range */
956 The priocntl() PC_GETCID and PC_GETCLINFO commands return fair-share
960 class attributes in the pc_clinfo buffer in this format.
961 fss_maxupri specifies the configured maximum user priority value for
964 the fair-share class. If fss_maxupri is x, the valid range for both
965 user priorities and user priority limits is from -x to +x.
966 A fssparms_t structure with the following members, defined in
969 <sys/fsspriocntl.h>, defines the format used to specify the fair-share
970 class-specific scheduling parameters of an LWP.
971 short fss_uprilim; /* Fair-share user priority limit */
973 short fss_upri; /* Fair-share user priority */
974 When using the priocntl() PC_SETPARMS or PC_GETPARMS commands, if
978 pc_cid specifies the fair-share class, the data in the pc_clparms buf‐
979 fer is in this format.
980 For the priocntl() PC_GETPARMS command, if pc_cid specifies the fair-
983 share class and more than one fair-share LWP is specified, the schedul‐
984 ing parameters of the fair-share LWP with the highest fss_upri value
985 among the specified LWPs is returned and the LWP ID of this LWP is
986 returned by the priocntl() call. If there is more than one LWP sharing
987 the highest user priority, the one returned is implementation-depen‐
988 dent.
989 Any fair-share LWP can lower its own fss_uprilim (or that of another
992 LWP with the same user ID). Only a fair-share LWP with sufficient priv‐
993 ileges can raise an fss_uprilim. When changing the class of an LWP to
994 fair-share from some other class, sufficient privileges are required to
995 enter the FSS class or to set the initial fss_uprilim to a value
996 greater than 0. Attempts by an unprivileged LWP to raise an fss_uprilim
997 or set an initial fss_uprilim greater than 0 fail with a return value
998 of -1 and errno set to EPERM.
999 Any fair-share LWP can set its own fss_upri (or that of another LWP
1002 with the same user ID) to any value less than or equal to the LWP's
1003 fss_uprilim. Attempts to set the fss_upri above the fss_uprilim (and/or
1004 set the fss_uprilim below the fss_upri) result in the fss_upri being
1005 set equal to the fss_uprilim.
1006 Either of the fss_uprilim or fss_upri members can be set to the special
1009 value FSS_NOCHANGE (defined in <sys/fsspriocntl.h>) to set one of the
1010 values without affecting the other. Specifying FSS_NOCHANGE for the
1011 fss_upri when the fss_uprilim is being set to a value below the current
1012 fss_upri causes the fss_upri to be set equal to the fss_uprilim being
1013 set. Specifying FSS_NOCHANGE for a parameter when changing the class of
1014 an LWP to fair-share (from some other class) causes the parameter to be
1015 set to a default value. The default value for the fss_uprilim is 0 and
1016 the default for the fss_upri is to set it equal to the fss_uprilim
1017 which is being set.
1018 The fair-share user priority and user priority limit are inherited
1021 across fork() and the exec family of functions.
1022
1024 The fixed-priority class provides a fixed-priority preemptive schedul‐
1025 ing policy for those LWPs requiring that the scheduling priorities do
1026 not get dynamically adjusted by the system and that the user/applica‐
1027 tion have control of the scheduling priorities.
1028 The fixed-priority class has a range of fixed-priority user priority
1031 (see fx_upri below) values that can be assigned to LWPs within the
1032 class. A fx_upri value of 0 is defined as the default base priority for
1033 the fixed-priority class. User priorities range from 0 to x where the
1034 value of x is configurable and can be determined for a specific instal‐
1035 lation by using the priocntl() PC_GETCID or PC_GETCLINFO command.
1036 The purpose of the user priority is to provide user/application control
1039 over the scheduling of processes in the fixed-priority class. For pro‐
1040 cesses in the fixed-priority class, the fx_upri value is, for all prac‐
1041 tical purposes, equivalent to the scheduling priority of the process.
1042 The fx_upri value completely determines the scheduling priority of a
1043 fixed-priority process relative to other processes within its class.
1044 Numerically higher fx_upri values represent higher priorities.
1045 In addition to the system-wide limits on user priority (returned by the
1048 PC_GETCID and PC_GETCLINFO commands), there is a per-LWP user priority
1049 limit (see fx_uprilim below) that specifies the maximum fx_upri value
1050 that can be set for a given LWP. By default, fx_uprilim is 0.
1051 A structure with the following member (defined in <sys/fxpriocntl.h>)
1054 defines the format used for the attribute data for the fixed-priority
1055 class.
1056 pri_t fx_maxupri; /* Maximum user priority */
1058 The priocntl() PC_GETCID and PC_GETCLINFO commands return fixed-prior‐
1062 ity class attributes in the pc_clinfo buffer in this format.
1063 The fx_maxupri member specifies the configured maximum user priority
1066 value for the fixed-priority class. If fx_maxupri is x, the valid range
1067 for both user priorities and user priority limits is from 0 to x.
1068 A structure with the following members (defined in <sys/fxpriocntl.h>)
1071 defines the format used to specify the fixed-priority class-specific
1072 scheduling parameters of an LWP.
1073 pri_t fx_upri; /* Fixed-priority user priority */
1075 pri_t fx_uprilim; /* Fixed-priority user priority limit */
1076 uint_t fx_tqsecs; /* seconds in time quantum */
1077 int fx_tqnsecs; /* additional nanosecs in time quant */
1078 When using the priocntl() PC_SETPARMS or PC_GETPARMS commands, if
1082 pc_cid specifies the fixed-priority class, the data in the pc_clparms
1083 buffer is in this format.
1084 For the priocntl() PC_GETPARMS command, if pc_cid specifies the fixed-
1087 priority class and more than one fixed-priority LWP is specified, the
1088 scheduling parameters of the fixed-priority LWP with the highest
1089 fx_upri value among the specified LWPs is returned and the LWP ID of
1090 this LWP is returned by the priocntl() call. If there is more than one
1091 LWP sharing the highest user priority, the one returned is implementa‐
1092 tion-dependent.
1093 Any fixed-priority LWP can lower its own fx_uprilim (or that of another
1096 LWP with the same user ID). Only a fixed-priority LWP with sufficient
1097 privileges can raise a fx_uprilim. When changing the class of an LWP to
1098 fixed-priority from some other class, sufficient privileges are
1099 required to set the initial fx_uprilim to a value greater than 0.
1100 Attempts by an unprivileged LWP to raise a fx_uprilim or set an initial
1101 fx_uprilim greater than 0 fail with a return value of -1 and errno set
1102 to EPERM.
1103 Any fixed-priority LWP can set its own fx_upri (or that of another LWP
1106 with the same user ID) to any value less than or equal to the LWP's
1107 fx_uprilim. Attempts to set the fx_upri above the fx_uprilim (and/or
1108 set the fx_uprilim below the fx_upri) result in the fx_upri being set
1109 equal to the fx_uprilim.
1110 Either of the fx_uprilim or fx_upri members can be set to the special
1113 value FX_NOCHANGE (defined in <sys/fxpriocntl.h>) to set one of the
1114 values without affecting the other. Specifying FX_NOCHANGE for the
1115 fx_upri when the fx_uprilim is being set to a value below the current
1116 fx_upri causes the fx_upri to be set equal to the fx_uprilim being set.
1117 Specifying FX_NOCHANGE for a parameter when changing the class of an
1118 LWP to fixed-priority (from some other class) causes the parameter to
1119 be set to a default value. The default value for the fx_uprilim is 0
1120 and the default for the fx_upri is to set it equal to the fx_uprilim
1121 that is being set. The default for time quantum is dependent on the
1122 fx_upri and on the system configuration; see fx_dptbl(4).
1123 The fx_tqsecs and fx_tqnsecs members are used for getting or setting
1126 the time quantum associated with an LWP or group of LWPs. fx_tqsecs is
1127 the number of seconds in the time quantum and fx_tqnsecs is the number
1128 of additional nanoseconds in the quantum. For example, setting
1129 fx_tqsecs to 2 and fx_tqnsecs to 500,000,000 (decimal) would result in
1130 a time quantum of two and one-half seconds. Specifying a value of
1131 1,000,000,000 or greater in the fx_tqnsecs member results in an error
1132 return with errno set to EINVAL. Although the resolution of the
1133 tq_nsecs member is very fine, the specified time quantum length is
1134 rounded up by the system to the next integral multiple of the system
1135 clock's resolution. The maximum time quantum that can be specified is
1136 implementation-specific and equal to INT_MAX ticks (defined in <lim‐
1137 its.h>). Requesting a quantum greater than this maximum results in an
1138 error return with errno set to ERANGE, although infinite quantums can
1139 be requested using a special value as explained below. Requesting a
1140 time quantum of 0 (setting both fx_tqsecs and fx_tqnsecs to 0) results
1141 in an error return with errno set to EINVAL.
1142 The fx_tqnsecs member can also be set to one of the following special
1145 values (defined in <sys/fxpriocntl.h>), in which case the value of
1146 fx_tqsecs is ignored:
1147 FX_TQINF Set an infinite time quantum.
1149 FX_TQDEF Set the time quantum to the default for this priority
1152 (see fx_dptbl(4)).
1153 FX_NOCHANGE Do not set the time quantum. This value is useful in
1156 changing the user priority of an LWP without affecting
1157 the time quantum. Specifying this value when changing
1158 the class of an LWP to fixed-priority from some other
1159 class is equivalent to specifying FX_TQDEF.
1160 When using the priocntl() PC_SETXPARMS or PC_GETXPARMS commands, the
1164 first argument after the command code must be the class name of the
1165 fixed-priority class (FX) . The next arguments are formed as (key,
1166 value) pairs, terminated by a 0 key. The definition for the keys of the
1167 fixed-priority class can be found in <sys/fxpriocntl.h>. A repeated
1168 specification of the same key results in an error return and errno set
1169 to EINVAL.
1170 ┌────────────────┬─────────────┬───────────────────────────────┐
1175 │ Key │Value Type │ Description │
1176 ├────────────────┼─────────────┼───────────────────────────────┤
1177 │FX_KY_UPRILIM │pri_t │user priority limit │
1178 │FX_KY_UPRI │pri_t │user priority │
1179 ├────────────────┼─────────────┼───────────────────────────────┤
1180 │FX_KY_TQSECS │uint_t │seconds in time quantum │
1181 ├────────────────┼─────────────┼───────────────────────────────┤
1182 │FX_KY_TQNSECS │int │nanoseconds in time quantum │
1183 └────────────────┴─────────────┴───────────────────────────────┘
1184 When using the priocntl() PC_GETXPARMS command, the value associated
1187 with the key is always a pointer to a scheduling parameter of the value
1188 type shown in the table above. In contrast, when using the priocntl()
1189 PC_SETXPARMS command, the scheduling parameter is given as a direct
1190 value.
1191 A priocntl() PC_SETXPARMS command with the class name (FX) and without
1194 a following (key, value) pair will set or reset all realtime scheduling
1195 parameters of the target process(es) to their default values. Changing
1196 the class of an LWP to fixed-priority from some other class causes the
1197 parameters to be set to their default values. The default value for the
1198 user priority limit (FX_KY_UPRILIM) is 0. The default value for the
1199 user priority (FX_KY_UPRI) is equal to the user priority limit
1200 (FX_KY_UPRILIM) that is being set. A default time quantum (FX_TQDEF) is
1201 assigned to each priority class (see fx_dptbl(4)).
1202 The value associated with FX_KY_TQSECS is the number of seconds in the
1205 time quantum. The value associated with FX_KY_TQNSECS is the number of
1206 nanoseconds in the quantum. Specifying a value of 1,000,000,000 or
1207 greater for the number of nanoseconds results in an error return and
1208 errno is set to EINVAL. The specified time quantum is rounded up by the
1209 system to the next integral multiple of the system clock's resolution.
1210 The maximum time quantum that can be specified is implementation-spe‐
1211 cific and equal to INT_MAX ticks, defined in <limits.h>. Requesting a
1212 quantum greater than this maximum results in an error return and errno
1213 is set to ERANGE. If seconds (FX_KY_TQSECS) but no nanoseconds
1214 (FX_KY_TQNSECS) are supplied, the number of nanoseconds is set to 0. If
1215 nanoseconds (FX_KY_TQNSECS) but no seconds (FX_KY_TQSECS) are supplied,
1216 the number of seconds is set to 0. A time quantum of 0 (seconds and
1217 nanoseconds are 0) results in an error return with errno set to EINVAL.
1218 Special values for FX_KY_TQSECS are FX_TQINF and FX_TQDEF (as described
1219 above). The priocntl() command PC_SETXPARMS knows no special value
1220 FX_NOCHANGE.
1221 The fixed-priority user priority and user priority limit are inherited
1224 across fork(2) and the exec family of functions.
1225
1227 Unless otherwise noted above, priocntl() returns 0 on success. On fail‐
1228 ure, priocntl() returns −1 and sets errno to indicate the error.
1229
1231 The priocntl() function will fail if:
1232 EAGAIN An attempt to change the class of an LWP failed because of
1234 insufficient resources other than memory (for example, class-
1235 specific kernel data structures).
1236 EFAULT One of the arguments points to an illegal address.
1239 EINVAL The argument cmd was invalid, an invalid or unconfigured
1242 class was specified, or one of the parameters specified was
1243 invalid.
1244 ENOMEM An attempt to change the class of an LWP failed because of
1247 insufficient memory.
1248 EPERM The {PRIV_PROC_PRIOCNTL} privilege is not asserted in the
1251 effective set of the calling LWP.
1252 The calling LWP does not have sufficient privileges to affect
1254 the target LWP.
1255 ERANGE The requested time quantum is out of range.
1258 ESRCH None of the specified LWPs exist.
1261
1264 priocntl(1), dispadmin(1M), init(1M), exec(2), fork(2), nice(2), prioc‐
1265 ntlset(2), fx_dptbl(4), process(4), rt_dptbl(4), privileges(5)
1266 System Administration Guide: Basic Administration
1269 Programming Interfaces Guide
1272SunOS 5.11 11 May 2006 priocntl(2)