class_scheduling(4) Kernel Interfaces Manual class_scheduling(4)
NAME
class_scheduling - Allocate CPU resources based on class.
DESCRIPTION
The Class Scheduler provides you with a method of controlling the execution of tasks or applications, by restricting the length of time
that they can access the processor (CPU).
For example, background daemons such as the print spooler can be given less access time. The CPU will then have more time available to
perform other tasks. To do this, you specify that the print daemon, /usr/lbin/lpd is allowed to use no more than a certain percentage of
the available CPU time. You can group resource user identifiers, such as a user's UID (User Identification), into classes and assign the
required CPU access time to each class.
This feature can help you to allocate system resources so that the most important work receives the required processing time. For example,
you may want to run two versions of a production database on your system. One version is used as part of your business operations, while
the other is a test copy, with different tuning parameters. The test database can be assigned to a different class so that your daily
operations are not impacted by the testing.
Users, groups, process groups, pids, and sessions can be collected into a class that is allotted a percentage of the CPU time. There may
be a number of classes on a system. The program class_admin(8) maintains a database of classes, class members, and percentage of CPU time
for the class. The database can be modified while the system is running and using class scheduling - changes take effect immediately.
Changes made by class_admin(8) may be saved to the disk with one exception: temporary data such as sessions and process groups, that have
no meaning on reboot, are kept only in memory.
In addition, a program may be forced to run in a specific class via the runclass(1) command with the restriction that the class must have
already been created by class_admin(8).
The kernel has very little knowledge of class scheduling. Much of the work is done in user space. A class, in the kernel, is an element
in an array of integers and a thread that is subject to class scheduling has knowledge of its' index in the array. Each time the thread
uses CPU time, the number of clock ticks used is decremented from the array element. When the count reaches zero, the thread is prevented
from running.
When class scheduling is enabled by class_admin(8), a daemon is started. The daemon wakes up periodically and calculates the total number
of clock ticks in the interval (wakeup interval seconds times clock ticks per second times number of CPUs). It then, for each class in the
database, divides the total by the percentage allocated to the class and places it into an array. When done, the array is written to the
kernel. Should the daemon terminate or fail to run, the system will automatically disable class scheduling. Classes previously scheduled
will then run free and unhampered.
A process may be represented in the database by more than one class. For instance: a group id representing the group "staff" may be in
class "A" and the user id representing the user "guest" may be in class "B". If user "guest" belongs to group "user", should the user then
belong to class "A" or to class "B"? The policy is that the class precedence goes from "broadest" to "narrowest". Therefore, in increas-
ing precedence the order is: group id, user id, session id, process group id, and process id. In the above example, user "guest" would be
placed in class "B".
Using Class Scheduling
To use the class scheduler, you must first create a database file and populate the file with one or more classes. Each class is assigned a
CPU value that controls its access to processing time, expressed as a percentage of the total CPU time availability. One or more applica-
tions or groups of applications can be assigned to a class, identified according to a unique system process identifier such as a PID or
UID. Note that identifiers that are temporary, such as a PID do not persist across a reboot and cease to exist when a task is completed.
is not stored in the database and has no effect when the system or task is restarted.
Once the database is established, you can enable class scheduling to start a class scheduling daemon and put the CPU access restrictions
into effect. Other commands enable you to review classes, change contents or scheduling parameters and delete components or entire
classes.
When a class scheduling database is configured and enabled, you can: Execute a task (process) according to the CPU access value set for a
specific class using runclass. For example, you might set a value for interactive operations that is much higher than background processes
such as print daemons. To temporarily use the higher value for a print job, you can execute the lpr command in the same class as interac-
tive operations. Execute class scheduling commands from within scripts using the command line version of class_admin. Execute class
scheduling commands from within programs, using the classcntl function.
The general process for setting up and using class scheduling is as follows: Decide how you want to allocate the CPU resources. Use
class_admin to set up and maintain the class database: Create classes and add members to the classes. Verify class entries using the show
command Save the entries to the /etc/class database Enable class scheduling, to start the daemon Use the stat command to check CPU usage
Execute class_admin commands from the command line or a shell script without running an interactive session Use the runclass command to
execute a task according to the priorities set for a particular class Use the classcntl function from within a program.
Note that it is not be necessary to perform tasks in this specific sequence. You can simply execute a series class_admin command from the
command line to configure a default database, add classes and class members, and enable the class scheduling daemon. The following sec-
tions suggest a systematic approach to using class scheduling, although you can use it equally well to create a quick fix to a CPU resource
sharing problem.
Planning Class Scheduling.
How you allocate CPU resources will depend on your system environment and what resources and priorities must be considered. A typical sce-
nario is to assign a higher priority to interactive tasks so that users do not encounter long response times. Most batch or background
processes will be assigned a lower priority, while some specific background processes may require a higher priority. For example, if a
nightly back up is being performed, you might not want it to have such a low priority that it does not complete in a reasonable time.
An alternative scenario is if there are critical realtime tasks that should take priority over interactive processes. For example, in
process control applications. For this scenario, you should design a baseline, assigning processes to classes and then monitor tasks and
user feedback to tune the database by moving tasks from class to class or changing the CPU access time of the classes.
Configuring Class Scheduler
The class_admin utility provides: An interactive command with sub-commands that enable you to create and administer a database of classes.
The database is stored in the file
/etc/class, which cannot be edited manually. A command mode that allows you to execute class_admin commands at the command prompt, or
include commands in shell scripts.
A database must be configured before you can enable class scheduling with the enable command. If a database does not exist when you enter
the class_admin command, the command will invoke an interactive session and prompt you to configure a database. If the class_admin com-
mand is invoked by a script, a database is configured automatically using the system defaults.
The following example shows an interactive configuration session: # class_admin
Class Scheduler Administration
configure:
Shall processes that have not been explicitly assigned to a defined class be assigned to a 'default' class? Enter (y/n) [n]: y
Enforce class scheduling when the CPU is otherwise idle? (y/n) [n]: y
How often do you want the system to reset class usage? Enter number of seconds (2): 5 class> The configuration values have the following
effect: To be scheduled, a process must be assigned to a class. If you answer y to the first prompt, a special class called the "default"
class is created. Any process that has not been explicitly assigned to a defined classes will be assigned to the default class.
If you answer n to this prompt, then only those processes which are explicitly assigned to a defined class will be class scheduled.
If you answer y to the second prompt, you allow classes to exceed their allotted CPU time percentage when the system is otherwise
idle. If you answer no, classes are restricted to their allotted percentage even if the CPU has no other work. The third prompt
allows you to set the standard reset time for all classes. For example, if you choose the short default time of 2 seconds, each
class will have more frequent, but shorter opportunities to access the CPU.
Use a small number (several seconds) if there are interactive jobs subject to class scheduling to give them a quick response time.
If only batch jobs are class scheduled, response time is not an issue and larger values may be used.
In the example, a default class was created and all current processes were assigned to that class. Class scheduling will be enforced even
when the CPU is idle and class usage will be reset every five seconds.
To review the current configuration, use the following command: class> show This command will produce output similar to the following: Con-
figuration:
-Processes not explicitly defined in the database are
class scheduled.
-If the processor has some idle time, class scheduled processes are not
allowed to exceed their cpu percentage.
-The class scheduler will check class CPU usage every 5 seconds.
Class scheduler status: disabled (For information on all class_admin command options, see the class_admin(8) reference page.)
The next step in the process is to create classes and populate the classes with system processes such as tasks, daemons, or user accounts.
Creating and Managing Classes
When the database has been configured, you can manage classes as follows: Create a class add processes to the class delete processes from a
class Change the CPU access value (time percentage) of any class Destroy an entire class, whether empty or populated Show details of class
members and configuration settings View statistics of actual CPU use against current priority settings
Creating a Class
To create a class, either use the command mode or enter an interactive session as follows: # class_admin class> create high_users 50 The
command mode version is entered as follows: # class_admin create batch_jobs 10 batch_jobs created at 10% cpu usage changes saved The first
command creates a class named high_users and assigns a CPU usage restriction of 50%. The second command creates a class named batch_jobs
and assigns a CPU usage restriction of 10%. Note that in command mode the changes are automatically saved to the database in /etc/class.
When making changes to classes interactively, you use the command save to commit changes to the database. If you attempt to end the ses-
sion with the quit command and there are unsaved changes, you will be prompted to save or discard the changes before quitting the interac-
tive session as follows: class> quit Class scheduler database modified. Save changes? (y/n) [y]: y changes saved
Managing Processes within a Class
Once you have created classes, you can add processes or sets of process to one or more classes using the add command. You must specify the
type of identifier (id) used and enter one or more unique identifiers. Identifiers can be obtained from system files or by using a command
such as the ps 1 command. For example: # ps aj Types allowed are: gid
A group identification number from the /etc/group file. This number will add all resource users that are assigned that number. uid
A user identification number from the /etc/passwd file. This number will add only the specific resource user to which the UID is
assigned. pgrp
A process group identifier, In the output from the ps command, see the entries under the PGID table heading session
The session identifier, obtained by using the ps command. In the output from this command, see the entries under the SESS table
heading. pid
The process identifier, obtained by using the ps In the output from this command, see the entries under the PID table heading.
It is most likely that you will use types uid and gid in your established classes, as these values will persist across a reboot or when
class scheduling is stopped and restarted. The identifiers associated with types pgrp, session, and pid are temporary, and will not exist
on reboot, or when a process terminates. You may want to use these types with the command runclass, or for temporarily adding certain pro-
cesses to a class by the use of a script.
The following command shows a sample of the system output that enables you to find the identifier for a running task or process: # ps -aj
USER PID PPID PGID SESS JOBC S TTY TIME COMMAND root 536 1 536 536 0 I + console 0:00.21 /usr/sbin/g dem
24884 24874 24884 24884 0 I + ttyp1 0:00.30 -csh (csh) root 7720 24371 7720 24371 1 R + ttyp2 0:00.03 ps aj walt 24371
24455 24371 24371 0 S ttyp2 0:00.98 -csh (csh) corc 24880 24903 24880 24903 1 R + ttyp3 0:37.57 sh /home/bi corc 24903
24894 24903 24903 0 I ttyp3 0:00.26 -csh (csh)
Adding Members to a Class
To add a process to a class, you use the add command as shown in the following interactive mode example: class> add batch_jobs uid 234 457
235 Note that you must use one of the unique identifiers previously specified and you cannot add the same identifier to a class more than
once.
The same procedure can be performed in command mode or from a script as follows: # add batch_jobs uid 234 457 235 uid 234 457 235 added to
high_users. In command mode, additions to a class are automatically saved to the /etc/class database.
Deleting Processes From a Class
To delete one or more processes from a class, use the delete command in interactive or command mode. For example: class> delete high_users
uid 11" uid 11 deleted from high_users
Other Class Management Options
Consult the class_admin(8) reference page for information on the following options: Change the priority of a class. For example:
class> change batch_jobs 20
batch_jobs retargeted at 20%. Destroy an entire class, whether empty or full. For example: class> destroy high_users
high_users is not empty. to destroy anyway? [y/n]: y high_users destroyed View statistics of actual CPU use against cur-
rent priority settings. For
example:
class> stats
Class scheduler status: enabled
class name target percentage actual percentage high_users 50% 40.0% batch_jobs
10% 2.0%
Using the runclass Command
Once you have established scheduler classes and enabled class-scheduling, you can use the runclass(1) command to execute a command in a
particular class. You must have root privileges to use this command if you want a higher CPU percentage than is currently assigned to
you. The following command uses the runclass command to open a terminal window and assign it to the previously-created high_users class:
# runclass high_users xterm The following command shows that the pgrp number for the terminal process is now identified as a member of that
class: # class_admin show
.
.
.
class members:
pgrp 24330 pgrp 24351 pgrp 24373 In this example, the identifier for the xterm process has been added to the class. You can
use the following command to view the running process: # ps agx | grep xterm
FILES
/etc/class, /usr/include/sys/class.h
RELATED INFORMATION
Commands: runclass(1), classcntl(2), class_admin(8). delim off
class_scheduling(4)