 |
Index for
Section 4 |
|
 |
Alphabetical
listing for C |
|
 |
Bottom of
page |
|
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 increasing 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 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.
Planning Class Scheduling.
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. 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 command 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:
Configuration:
-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 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
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 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)
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 current 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).
|
Index for
Section 4 |
|
|
Alphabetical
listing for C |
|
 |
Top of
page |
|