class_scheduling - Allocate CPU resources based on class.
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 goup "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 increasing precendence 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".
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 applications 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 interactive 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 sections 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.
How you allocate CPU resources will depend on your system environment and what resources and priorities must be considered. A typical scenario 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. Digital recommends that you 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.
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 commmand will invoke an interactive session and prompt you to configure a database. If the class_admin command is invoked by a script, a database is configured automatically using the system defaults.
The following example shows an interactive configuration session:
Class Scheduler Administration
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.
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:
This command will produce output similar to the following:
-Processes not explicitly defined in the database are
-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.
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
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 attemp to end the session with the quit command and there are unsaved changes, you will be prompted to save or discard the changes before quitting the interactive session as follows: class> quit Class scheduler database modified. Save changes? (y/n) [y]: y changes saved
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 sytem files or by using a command such as the ps 1 command. For example: # ps aj Types allowed are: gid
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 processes 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)
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.
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
Consult the class_admin(8) reference page for information on the
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
View statistics of actual CPU use against current priority settings. For
Class scheduler status: enabled
class name target percentage actual percentage
high_users 50% 40.0%
batch_jobs 10% 2.0%
Once you have established scheduler classes and enabled
class-scheduling, you can use the
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
command to open a terminal
window and assign it to the previously-created
# runclass high_users xterm
The following command shows that the
number for the terminal
process is now identified as a member of that class:
# class_admin show
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
Commands: runclass(1), classcntl(2), class_admin(8). delim off delim off