1priocntl(1)                      User Commands                     priocntl(1)
2
3
4

NAME

6       priocntl   -   display   or  set  scheduling  parameters  of  specified
7       process(es)
8

SYNOPSIS

10       priocntl -l
11
12
13       priocntl -d [-i idtype] [idlist]
14
15
16       priocntl -s [-c class] [class-specific options]
17            [-i idtype] [idlist]
18
19
20       priocntl -e [-c class] [class-specific options] command
21            [argument(s)]
22
23

DESCRIPTION

25       The priocntl command displays or  sets  scheduling  parameters  of  the
26       specified  process(es). It can also be used to display the current con‐
27       figuration information for the system's process scheduler or execute  a
28       command with specified scheduling parameters.
29
30
31       Processes  fall into distinct classes with a separate scheduling policy
32       applied to each class. The process classes currently supported are  the
33       real-time  class,  time-sharing  class,  interactive  class, fair-share
34       class, and the fixed  priority  class.  The  characteristics  of  these
35       classes  and the class-specific options they accept are described below
36       in the USAGE section under the headings Real-Time  Class,  Time-Sharing
37       Class,  Inter-Active Class, Fair-Share Class, and Fixed-Priority Class.
38       With appropriate permissions, the priocntl command can change the class
39       and other scheduling parameters associated with a running process.
40
41
42       In  the default configuration, a runnable real-time process runs before
43       any other process. Therefore, inappropriate use of real-time  processes
44       can have a dramatic negative impact on system performance.
45
46
47       If  an  idlist  is present, it must appear last on the command line and
48       the elements of the list must be separated by white space. If no idlist
49       is  present, an idtype argument of pid, ppid, pgid, sid, taskid, class,
50       uid, gid, projid, or zoneid specifies the process  ID,  parent  process
51       ID,  process  group  ID, session ID, task ID, class, user ID, group ID,
52       project ID, or zone ID, respectively, of the priocntl command itself.
53
54
55       The command
56
57         priocntl -d [-i idtype] [idlist]
58
59
60
61
62       displays the class and  class-specific  scheduling  parameters  of  the
63       process(es) specified by idtype and idlist.
64
65
66       The command
67
68         priocntl -s [-c class] [class-specific options] \
69              [-i idtype] [idlist]
70
71
72
73
74       sets the class and class-specific parameters of the specified processes
75       to the values given on the command line. The -c class option  specifies
76       the  class  to be set. (The valid class arguments are RT for real-time,
77       TS for time-sharing, IA for inter-active, FSS for fair-share, or FX for
78       fixed-priority.)
79
80
81       The class-specific parameters to be set are specified by the class-spe‐
82       cific options as explained under the appropriate heading below. If  the
83       -c  class  option  is  omitted, idtype and idlist must specify a set of
84       processes which are all in the same class, otherwise an error  results.
85       If  no  class-specific  options are specified, the process's class-spe‐
86       cific parameters are set to the default values for the class  specified
87       by  -c class (or to the default parameter values for the process's cur‐
88       rent class if the -c class option is also omitted).
89
90
91       In order to change the scheduling parameters of a process using  prioc‐
92       ntl  the  real or effective user ID (respectively, groupID) of the user
93       invoking priocntl must match the real or  effective  user  ID  (respec‐
94       tively,  groupID)  of the receiving process or the effective user ID of
95       the user must be super-user. These are the minimum permission  require‐
96       ments  enforced  for  all classes. An individual class can impose addi‐
97       tional permissions requirements when setting processes to that class or
98       when setting class-specific scheduling parameters.
99
100
101       When idtype and idlist specify a set of processes, priocntl acts on the
102       processes in the set in an implementation-specific order.  If  priocntl
103       encounters  an error for one or more of the target processes, it can or
104       cannot continue through the set of processes, depending on  the  nature
105       of the error.
106
107
108       If  the  error is related to permissions, priocntl prints an error mes‐
109       sage and then continues through the process set, resetting the  parame‐
110       ters  for  all target processes for which the user has appropriate per‐
111       missions. If priocntl encounters an error other  than  permissions,  it
112       does  not  continue through the process set but prints an error message
113       and exits immediately.
114
115
116       A special sys scheduling class exists for the purpose of scheduling the
117       execution  of  certain  special  system  processes (such as the swapper
118       process). It is not possible to change the class of any process to sys.
119       In  addition,  any  processes in the sys class that are included in the
120       set of processes specified by idtype and idlist are disregarded by pri‐
121       ocntl.  For example, if idtype were uid, an idlist consisting of a zero
122       would specify all processes with a UID of 0, except  processes  in  the
123       sys class and (if changing the parameters using the -s option) the init
124       process.
125
126
127       The init process (process ID 1) is a special case.  In  order  for  the
128       priocntl  command to change the class or other scheduling parameters of
129       the init process, idtype must be pid and idlist must be consist of only
130       a  1.  The  init process can be assigned to any class configured on the
131       system, but the time-sharing class is  almost  always  the  appropriate
132       choice.  Other choices can be highly undesirable; see the System Admin‐
133       istration Guide: Basic Administration for more information.
134
135
136       The command
137
138         priocntl -e [-c class] [class-specific options] command \
139              [argument...]
140
141
142
143
144       executes the specified command with the class and scheduling parameters
145       specified  on the command line (arguments are the arguments to the com‐
146       mand). If the -c class option is omitted the  command  is  run  in  the
147       user's current class.
148

OPTIONS

150       The following options are supported:
151
152       -c class     Specifies  the class to be set. (The valid class arguments
153                    are RT for real-time, TS for time-sharing, IA  for  inter-
154                    active,  FSS for fair-share, or FX for fixed-priority.) If
155                    the specified class is not already configured, it is auto‐
156                    matically configured.
157
158
159       -d           Displays  the  scheduling parameters associated with a set
160                    of processes.
161
162
163       -e           Executes a specified command with the class and scheduling
164                    parameters associated with a set of processes.
165
166
167       -i idtype    This  option, together with the idlist arguments (if any),
168                    specifies one or more processes to which the priocntl com‐
169                    mand  is to apply. The interpretation of idlist depends on
170                    the value of idtype. If the -i idtype  option  is  omitted
171                    when  using the -d or -s options the default idtype of pid
172                    is assumed.
173
174                    The valid idtype arguments and  corresponding  interpreta‐
175                    tions of idlist are as follows:
176
177                    -i all       The  priocntl command applies to all existing
178                                 processes. No idlist should be specified  (if
179                                 one is specified, it is ignored). The permis‐
180                                 sion  restrictions  described   below   still
181                                 apply.
182
183
184                    -i ctid      idlist is a list of process contract IDs. The
185                                 priocntl command  applies  to  all  processes
186                                 with  a  process  contract  ID equal to an ID
187                                 from the list.
188
189
190                    -i class     idlist consists of a single  class  name  (RT
191                                 for  real-time,  TS  for time-sharing, IA for
192                                 inter-active, FSS for fair-share, or  FX  for
193                                 fixed-priority). The priocntl command applies
194                                 to all processes in the specified class.
195
196
197                    -i gid       idlist is a list of group IDs.  The  priocntl
198                                 command  applies  to  all  processes  with an
199                                 effective group ID equal to an  ID  from  the
200                                 list.
201
202
203                    -i pgid      idlist  is  a  list of process group IDs. The
204                                 priocntl command applies to all processes  in
205                                 the specified process groups.
206
207
208                    -i pid       idlist is a list of process IDs. The priocntl
209                                 command applies to the specified processes.
210
211
212                    -i ppid      idlist is a list of parent process  IDs.  The
213                                 priocntl  command  applies  to  all processes
214                                 whose parent process ID is in the list.
215
216
217                    -i projid    idlist is a list of project IDs. The priocntl
218                                 command  applies  to  all  processes  with an
219                                 effective project ID equal to an ID from  the
220                                 list.
221
222
223                    -i sid       idlist is a list of session IDs. The priocntl
224                                 command applies to all processes in the spec‐
225                                 ified sessions.
226
227
228                    -i taskid    idlist  is  a  list of task IDs. The priocntl
229                                 command applies to all processes in the spec‐
230                                 ified tasks.
231
232
233                    -i uid       idlist  is  a  list of user IDs. The priocntl
234                                 command applies  to  all  processes  with  an
235                                 effective  user  ID  equal  to an ID from the
236                                 list.
237
238
239                    -i zoneid    idlist is a list of zone  IDs.  The  priocntl
240                                 command  applies  to  all  processes  with an
241                                 effective zone ID equal to  an  ID  from  the
242                                 list.
243
244
245
246       -l           Displays a list of the classes currently configured in the
247                    system along with class-specific  information  about  each
248                    class.  The  format of the class-specific information dis‐
249                    played is described under USAGE.
250
251
252       -s           Sets the scheduling parameters associated with  a  set  of
253                    processes.
254
255
256
257       The valid class-specific options for setting real-time parameters are:
258
259       -p rtpri             Sets  the  real-time  priority  of  the  specified
260                            process(es) to rtpri.
261
262
263       -t tqntm [-r res]    Sets the time quantum of the specified process(es)
264                            to  tqntm. You can optionally specify a resolution
265                            as explained below.
266
267
268       -q tqsig             Sets the real-time  time  quantum  signal  of  the
269                            specified process(es) to tqsig.
270
271
272
273       The  valid  class-specific  options for setting time-sharing parameters
274       are:
275
276       -m tsuprilim    Sets  the  user  priority  limit   of   the   specified
277                       process(es) to tsuprilim.
278
279
280       -p tsupri       Sets  the user priority of the specified process(es) to
281                       tsupri.
282
283
284
285       The valid class-specific options for  setting  inter-active  parameters
286       are:
287
288       -m iauprilim    Sets   the   user   priority  limit  of  the  specified
289                       process(es) to iauprilim.
290
291
292       -p iaupri       Sets the user priority of the specified process(es)  to
293                       iaupri.
294
295
296
297       The valid class-specific options for setting fair-share parameters are:
298
299       -m fssuprilim    Sets   the   user  priority  limit  of  the  specified
300                        process(es) to fssuprilim.
301
302
303       -p fssupri       Sets the user priority of the specified process(es) to
304                        fssupri.
305
306
307
308       The  valid class-specific options for setting fixed-priority parameters
309       are:
310
311       -m fxuprilim    Sets  the  user  priority  limit   of   the   specified
312                       process(es) to fxuprilim.
313
314
315       -p fxupri       Sets  the user priority of the specified process(es) to
316                       fxupri.
317
318
319       -t tqntm        [-r  res]  Sets  the  time  quantum  of  the  specified
320                       process(es) to tqntm. You can optionally specify a res‐
321                       olution as explained below.
322
323

USAGE

325   Real-Time Class
326       The real-time class provides a  fixed  priority  preemptive  scheduling
327       policy  for  those  processes requiring fast and deterministic response
328       and absolute user/application control of scheduling priorities. If  the
329       real-time  class  is configured in the system, it should have exclusive
330       control of the highest range of scheduling priorities  on  the  system.
331       This  ensures  that  a  runnable real-time process is given CPU service
332       before any process belonging to any other class.
333
334
335       The real-time class has a range of real-time  priority  (rtpri)  values
336       that  can  be assigned to processes within the class. Real-time priori‐
337       ties range from 0 to x, where the value of x is configurable and can be
338       displayed  for  a  specific  installation that has already configured a
339       real-time scheduler, by using the command
340
341         priocntl -l
342
343
344
345
346       The real-time scheduling policy is a fixed priority policy. The  sched‐
347       uling  priority  of  a  real-time  process  never changes except as the
348       result of an explicit request by the  user/application  to  change  the
349       rtpri value of the process.
350
351
352       For processes in the real-time class, the rtpri value is, for all prac‐
353       tical purposes, equivalent to the scheduling priority of  the  process.
354       The  rtpri  value  completely  determines  the scheduling priority of a
355       real-time process relative to other processes within its class. Numeri‐
356       cally  higher rtpri values represent higher priorities. Since the real-
357       time class controls the highest range of scheduling priorities  in  the
358       system,  it  is guaranteed that the runnable real-time process with the
359       highest rtpri value is always selected to run before any other  process
360       in the system.
361
362
363       In  addition  to providing control over priority, priocntl provides for
364       control over the length of the time quantum allotted  to  processes  in
365       the  real-time  class.  The  time  quantum  value specifies the maximum
366       amount of time a process can run, assuming that it does not complete or
367       enter  a  resource  or event wait state (sleep). Notice that if another
368       process becomes runnable at a higher priority,  the  currently  running
369       process can be preempted before receiving its full time quantum.
370
371
372       The command
373
374         priocntl -d [-i idtype] [idlist]
375
376
377
378
379       displays  the  real-time priority, time quantum (in millisecond resolu‐
380       tion), and time quantum signal value for each real-time process in  the
381       set specified by idtype and idlist.
382
383
384       Any  combination  of  the  -p, -t [-r], and -q options can be used with
385       priocntl -s or priocntl -e for the real-time class.  If  an  option  is
386       omitted  and the process is currently real-time, the associated parame‐
387       ter is unaffected. If an option is omitted when changing the class of a
388       process to real-time from some other class, the associated parameter is
389       set to a default value. The default  value  for  rtpri  is  0  and  the
390       default  for time quantum is dependent on the value of rtpri and on the
391       system configuration; see rt_dptbl(4).
392
393
394       When using the -t tqntm option, you can optionally specify a resolution
395       using  the  -r  res option. (If no resolution is specified, millisecond
396       resolution is assumed.) If res is specified,  it  must  be  a  positive
397       integer between 1 and 1,000,000,000 inclusively and the resolution used
398       is the reciprocal of res in seconds. For example, specifying -t  10  -r
399       100  would set the resolution to hundredths of a second and the result‐
400       ing time quantum length would be 10/100 seconds (one tenth  of  a  sec‐
401       ond).  Although very fine (nanosecond) resolution can be specified, the
402       time quantum length is rounded up by the system to  the  next  integral
403       multiple   of the system clock's resolution. Requests for time quantums
404       of zero or quantums greater than the (typically very large) implementa‐
405       tion-specific maximum quantum result in an error.
406
407
408       The  real-time  time quantum signal can be used to notify runaway real-
409       time processes about the consumption of their time quantum. Those  pro‐
410       cesses,  which  are  monitored  by  the  real-time time quantum signal,
411       receive the configured signal in the event of time quantum  expiration.
412       The  default value (0) of the time quantum signal tqsig denotes no sig‐
413       nal delivery. A positive value denotes the delivery of the signal spec‐
414       ified  by  the value. Like kill(1) and other commands operating on sig‐
415       nals, the -q tqsig option is also able  to  handle  symbolically  named
416       signals, like XCPU or KILL.
417
418
419       In  order to change the class of a process to real-time (from any other
420       class), the user invoking priocntl must have super-user  privilege.  In
421       order to change the rtpri value or time quantum of a real-time process,
422       the user invoking priocntl must either be super-user, or must currently
423       be in the real-time class (shell running as a real-time process) with a
424       real or effective user ID matching the real or effective user ID of the
425       target process.
426
427
428       The  real-time  priority,  time  quantum,  and  time quantum signal are
429       inherited across the fork(2) and exec(2) system calls. When  using  the
430       time  quantum  signal  with  a  user  defined signal handler across the
431       exec(2) system call, the new image must  install  an  appropriate  user
432       defined  signal  handler  before  the  time quantum expires. Otherwise,
433       unpredicable behavior would result.
434
435   Time-Sharing Class
436       The time-sharing scheduling policy provides for a  fair  and  effective
437       allocation  of  the  CPU resource among processes with varying CPU con‐
438       sumption characteristics. The objectives of the time-sharing policy are
439       to  provide  good  response  time  to  interactive  processes  and good
440       throughput to CPU-bound jobs, while providing a degree of user/applica‐
441       tion control over scheduling.
442
443
444       The  time-sharing  class  has  a  range  of  time-sharing user priority
445       (tsupri) values that can be assigned to  processes  within  the  class.
446       User  priorities  range  from −x to +x, where the value of x is config‐
447       urable. The range for a specific installation can be displayed by using
448       the command
449
450         priocntl -l
451
452
453
454
455       The  purpose  of  the  user  priority  is  to  provide  some  degree of
456       user/application control over the scheduling of processes in the  time-
457       sharing class. Raising or lowering the tsupri value of a process in the
458       time-sharing class raises or lowers  the  scheduling  priority  of  the
459       process.  It  is  not  guaranteed, however, that a time-sharing process
460       with a higher tsupri value runs before one with a lower  tsupri  value.
461       This  is  because the tsupri value is just one factor used to determine
462       the scheduling priority of  a  time-sharing  process.  The  system  can
463       dynamically  adjust  the internal scheduling priority of a time-sharing
464       process based on other factors such as recent CPU usage.
465
466
467       In addition to the system-wide limits on user priority (displayed  with
468       priocntl  -l),  there is a per process user priority limit (tsuprilim),
469       which specifies the maximum tsupri value that can be set  for  a  given
470       process.
471
472
473       The command
474
475         priocntl -d [-i idtype] [idlist]
476
477
478
479
480       displays  the user priority and user priority limit for each time-shar‐
481       ing process in the set specified by idtype and idlist.
482
483
484       Any time-sharing process can  lower  its  own  tsuprilim  (or  that  of
485       another  process  with  the  same user ID). Only a time-sharing process
486       with super-user privilege can raise  a  tsuprilim.  When  changing  the
487       class  of  a  process to time-sharing from some other class, super-user
488       privilege is required in order to set the initial tsuprilim to a  value
489       greater than zero.
490
491
492       Any  time-sharing  process  can  set its own tsupri (or that of another
493       process with the same user ID) to any value less than or equal  to  the
494       process's  tsuprilim.  Attempts  to  set the tsupri above the tsuprilim
495       (and/or set the tsuprilim below the tsupri) result in the tsupri  being
496       set equal to the tsuprilim.
497
498
499       Any  combination  of the -m and -p options can be used with priocntl -s
500       or priocntl -e for the time-sharing class. If an option is omitted  and
501       the process is currently time-sharing, the associated parameter is nor‐
502       mally unaffected. The exception is when the -p option is omitted and -m
503       is  used to set a tsuprilim below the current tsupri. In this case, the
504       tsupri is set equal to the tsuprilim which is being set. If  an  option
505       is  omitted  when  changing the class of a process to time-sharing from
506       some other class, the associated parameter is set to a  default  value.
507       The  default  value for tsuprilim is 0 and the default for tsupri is to
508       set it equal to the tsuprilim value which is being set.
509
510
511       The time-sharing user priority and user priority  limit  are  inherited
512       across the fork(2) and exec(2) system calls.
513
514   Inter-Active Class
515       The  inter-active  scheduling  policy provides for a fair and effective
516       allocation of the CPU resource among processes with  varying  CPU  con‐
517       sumption  characteristics  while providing good responsiveness for user
518       interaction. The objectives of the inter-active policy are  to  provide
519       good response time to interactive processes and good throughput to CPU-
520       bound jobs. The priorities of processes in the inter-active  class  can
521       be  changed  in  the  same  manner  as those in the time-sharing class,
522       though the modified priorities continue to be adjusted to provide  good
523       responsiveness for user interaction.
524
525
526       The  inter-active user priority limit, iaupri, is equivalent to tsupri.
527       The inter-active per process user priority, iauprilim, is equivalent to
528       tsuprilim.
529
530
531       Inter-active  class processes that have the iamode ("interactive mode")
532       bit set are given a priority boost value of 10, which is factored  into
533       the  user  mode  priority of the process when that calculation is made,
534       that is, every time a process's priority is adjusted. This  feature  is
535       used by the X windowing system, which sets this bit for those processes
536       that run inside of the current active window to give them a higher pri‐
537       ority.
538
539   Fair-Share Class
540       The  fair-share  scheduling policy provides a fair allocation of system
541       CPU resources among projects, independent of the  number  of  processes
542       they  own.  Projects are given "shares" to control their entitlement to
543       CPU resources. Resource usage is remembered over time, so that entitle‐
544       ment  is  reduced  for heavy usage, and increased for light usage, with
545       respect to other  projects.  CPU  time  is  scheduled  among  processes
546       according  to  their owner's entitlements, independent of the number of
547       processes each project owns.
548
549
550       The FSS scheduling class supports the notion of per-process user prior‐
551       ity  and  user  priority  limit  for  compatibility with the time-share
552       scheduler. The fair share  scheduler  attempts  to  provide  an  evenly
553       graded effect across the whole range of user priorities. Processes with
554       negative fssupri values receive time slices less frequently  than  nor‐
555       mal,   while processes with positive fssupri values receive time slices
556       more  frequently than normal.   Notice  that  user  priorities  do  not
557       interfere  with  shares. That is, changing a fssupri value of a process
558       is not going to affect its  project's  overall  CPU  usage  which  only
559       relates  to  the  amount  of  shares  it is allocated compared to other
560       projects.
561
562
563       The priorities of processes in the fair-share class can be  changed  in
564       the same manner as those in the time-share class.
565
566   Fixed-Priority Class
567       The  fixed-priority class provides a fixed priority preemptive schedul‐
568       ing policy for those processes requiring that the scheduling priorities
569       do  not get dynamically adjusted by the system and that the user/appli‐
570       cation have control of the scheduling priorities.
571
572
573       The fixed-priority class shares the same range of scheduling priorities
574       with the time-sharing class, by default. The fixed-priority class has a
575       range of fixed-priority user  priority  (fxupri)  values  that  can  be
576       assigned to processes within the class. User priorities range from 0 to
577       x, where the value of x is  configurable.  The  range  for  a  specific
578       installation can be displayed by using the command
579
580         priocntl -l
581
582
583
584
585       The purpose of the user priority is to provide user/application control
586       over the scheduling of processes in the fixed-priority class. For  pro‐
587       cesses  in the fixed-priority class, the fxupri value is, for all prac‐
588       tical purposes, equivalent  to the scheduling priority of the  process.
589       The  fxupri  value  completely  determines the scheduling priority of a
590       fixed-priority process relative to other processes  within  its  class.
591       Numerically higher fxupri values represent higher priorities.
592
593
594       In  addition to the system-wide limits on user priority (displayed with
595       priocntl  -l), there is a per process user priority  limit (fxuprilim),
596       which  specifies  the  maximum fxupri value that can be set for a given
597       process.
598
599
600       Any fixed-priority process can lower its  own  fxuprilim  (or  that  of
601       another  process with the same user ID). Only a process with super-user
602       privilege can raise a fxuprilim. When changing the class of  a  process
603       to  fixed-priority  from  some  other  class,  super-user  privilege is
604       required in order to set the initial fxuprilim to a value greater  than
605       zero.
606
607
608       Any  fixed-priority  process can set its own fxupri (or that of another
609       process with the same user ID) to any value less than or equal  to  the
610       process's fxuprilim. Attempts to set the fxupri above the fxuprilim (or
611       set the fxuprilim below the fxupri) result  in  the  fxupri  being  set
612       equal to the fxuprilim.
613
614
615       In  addition  to providing control over priority, priocntl provides for
616       control over the length of the time quantum allotted  to  processes  in
617       the  fixed-priority class. The time quantum value specifies the maximum
618       amount of time a process can run, before surrendering the CPU, assuming
619       that  it  does  not  complete  or  enter a resource or event wait state
620       (sleep). Notice that if another process becomes runnable  at  a  higher
621       priority, the currently running process can be preempted before receiv‐
622       ing its full time quantum.
623
624
625       Any combination of the -m, -p, and -t options can be used with priocntl
626       -s or priocntl -e for the fixed-priority class. If an option is omitted
627       and the process is currently fixed-priority, the  associated  parameter
628       is  normally unaffected. The exception is when the -p option is omitted
629       and the -m option is used to set a fxuprilim below the current  fxupri.
630       In  this  case, the fxupri is set equal to the fxuprilim which is being
631       set. If an option is omitted when changing the class of  a  process  to
632       fixed-priority  from  some other class, the associated parameter is set
633       to a default value. The default value for fxuprilim is 0.  The  default
634       for  fxupri  is  to  set it equal to the fxuprilim value which is being
635       set. The default for time quantum is dependent on the fxupri and on the
636       system configuration. See fx_dptbl(4).
637
638
639       The  time  quantum of processes in the fixed-priority class      can be
640       changed in the same manner as those in the real-time class.
641
642
643       The fixed-priority user priority, user priority limit, and time quantum
644       are inherited across the fork(2) and exec(2) system calls.
645

EXAMPLES

647       The following are real-time class examples:
648
649       Example 1 Setting the Class
650
651
652       The  following  example  sets  the class of any non-real-time processes
653       selected by idtype and idlist to real-time  and  sets  their  real-time
654       priority  to  the  default  value of 0. The real-time priorities of any
655       processes currently in the real-time class  are  unaffected.  The  time
656       quantums of all of the specified processes are set to 1/10 seconds.
657
658
659         example% priocntl -s -c RT -t 1 -r 10 -i idtype idlist
660
661
662
663       Example 2 Executing a Command in Real-time
664
665
666       The  following  example  executes command in the real-time class with a
667       real-time priority of 15 and a time quantum of 20 milliseconds:
668
669
670         example% priocntl -e -c RT -p 15 -t 20 command
671
672
673
674       Example 3 Executing a Command in Real-time  with  a  Specified  Quantum
675       Signal
676
677
678       The  following  example  executes command in the real-time class with a
679       real-time priority of 11, a time quantum of 250 milliseconds, and where
680       the specified real-time quantum signal is SIGXCPU:
681
682
683         example% priocntl -e -c RT -p 11 -t 250 -q XCPU command
684
685
686
687
688       The following are time-sharing class examples:
689
690       Example 4 Setting the Class of non-time-sharing Processes
691
692
693       The  following example sets the class of any non-time-sharing processes
694       selected by idtype and idlist to time-sharing and sets both their  user
695       priority  limit  and user priority to 0. Processes already in the time-
696       sharing class are unaffected.
697
698
699         example% priocntl -s -c TS -i idtype idlist
700
701
702
703       Example 5 Executing a Command in the Time-sharing Class
704
705
706       The following example executes command with the arguments arguments  in
707       the  time-sharing class with a user priority limit of 0 and a user pri‐
708       ority of −15:
709
710
711         example% priocntl -e -c TS -m 0 -p -15 command [arguments]
712
713
714
715       Example 6 Executing a Command in Fixed-Priority Class
716
717
718       The following example executes a command in the  fixed-priority   class
719       with a user priority limit of 20 and user priority of 10 and time quan‐
720       tum of 250 milliseconds:
721
722
723         example% priocntl -e -c FX -m 20 -p 10 -t 250 command
724
725
726

EXIT STATUS

728       The following exit values are returned:
729
730
731       For options -d, -l, and -s:
732
733       0    Successful operation.
734
735
736       1    Error condition.
737
738
739
740       For option -e:
741
742
743       Return of the Exit Status of the executed  command  denotes  successful
744       operation. Otherwise,
745
746       1    Command could not be executed at the specified priority.
747
748

ATTRIBUTES

750       See attributes(5) for descriptions of the following attributes:
751
752
753
754
755       ┌─────────────────────────────┬─────────────────────────────┐
756       │      ATTRIBUTE TYPE         │      ATTRIBUTE VALUE        │
757       ├─────────────────────────────┼─────────────────────────────┤
758       │Availability                 │SUNWcsu                      │
759       ├─────────────────────────────┼─────────────────────────────┤
760       │CSI                          │Enabled                      │
761       └─────────────────────────────┴─────────────────────────────┘
762

SEE ALSO

764       kill(1),  nice(1), ps(1), dispadmin(1M), exec(2), fork(2), priocntl(2),
765       fx_dptbl(4), process(4), rt_dptbl(4), attributes(5), zones(5), FSS(7)
766
767
768       System Administration Guide: Basic Administration
769

DIAGNOSTICS

771       priocntl prints the following error messages:
772
773       Process(es) not found
774
775           None of the specified processes exists.
776
777
778       Specified processes from different classes
779
780           The -s option is being used to set parameters, the -c class  option
781           is  not  present, and processes from more than one class are speci‐
782           fied.
783
784
785       Invalid option or argument
786
787           An unrecognized or invalid option or option argument is used.
788
789
790
791
792SunOS 5.11                        1 Apr 2008                       priocntl(1)
Impressum