*nix Documentation Project
·  Home
 +   man pages
·  Linux HOWTOs
·  FreeBSD Tips
·  *niX Forums

  man pages->Tru64 Unix man pages -> class_scheduling (4)              



NAME    [Toc]    [Back]

       class_scheduling,  class.h  - Allocate CPU resources based
       on scheduling classes

SYNOPSIS    [Toc]    [Back]

       #include <sys/class.h>

DESCRIPTION    [Toc]    [Back]

       The class scheduling features included  in  the  operating
       system  software  let  you  restrict the percentage of CPU
       time allowed different kinds  of  users  and  tasks.  This
       helps  you  allocate CPU resources so that the most important
 work receives the processing time  it  requires.  For
       example,  you  might 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 class that has a lower percentage of
       CPU time so that your daily operations are not impacted by
       the  testing.  As  another example, you might want to give
       background daemons, such as the print spooler, less access
       time  to  CPUs  to  improve  response time for interactive

       By using the class_admin  utility,  you  can:  Create  and
       maintain one or more databases of scheduling classes, each
       of which has a  specified  percentage  of  CPU  time.  The
       databases are typically stored in the /etc/class directory
       and cannot be edited manually. You can  set  up  different
       class  databases  for  different  time  intervals during a
       24-hour period (for  example,  one  database  that  favors
       interactive  users  during the day and another that favors
       batch jobs at night). A class_admin load command can  then
       be included as a cron job to load the appropriate database
       into shared memory at a certain time.  Assign  members  to
       different  classes. Members assigned to a particular class
       can be users, groups, processes, process groups, sessions,
       or some combination of these.  Enable and disable the daemon
 that schedules execution of different tasks  according
       to  what  you've  defined in the database currently loaded
       into memory. Among the configuration parameters you supply
       during setup of the class database is a time interval that
       controls how often the daemon refreshes the structure used
       by  the  kernel to implement your class scheduling priorities.

       You cannot use the class_admin utility to add  application
       names  to  a class. However, after defining a class in the
       current database and enabling class  scheduling,  you  can
       use  runclass  commands  to launch programs in that class.
       When you do this, identifiers for all the application processes
 are automatically added as members of the specified
       class. The runclass command is particularly  useful  as  a
       cron  job  that  executes after the one that enables class
       scheduling and loads a particular class database into memory.

       The  libclass  library  provides  programming routines for
       setting up and using class scheduling. The name  for  each
       routine  in  this library uses the format class_operation,
       for example class_create(). A complete list of routines is
       provided in the SEE ALSO section.

   How Class Scheduling Works    [Toc]    [Back]
       The  kernel  has  very  little internal knowledge of class
       scheduling.  Much of the work done by the class  scheduler
       is done in user space. To the kernel, a class is simply an
       element in an array of integers, each specifying a  number
       of  clock  ticks  that  are  available  for a certain time
       interval. The time interval is set when the class scheduling
  database  is configured, and the integer values vary,
       depending on the CPU percentage specified for the  different
  classes. A thread that is subject to class scheduling
       has an index into the array. Each time the thread uses CPU
       time, the kernel decrements the number of clock ticks used
       from the array element. When the count reaches  zero,  the
       thread is prevented from running.

       A  class database can be configured to impose CPU percentages
 in either a hard or soft way. Hard  percentages  (the
       default)  mean  that, once a thread uses its allotted percentage
 of CPU time, it is prevented  from  running  until
       the  next time interval. Soft percentages mean that thread
       execution can continue after the CPU percentage is reached
       if the system has idle CPUs (if there is no contention for
       CPU time among users). Hard percentages risk  wasting  CPU
       cycles;  however,  they  are  appropriate  for a system on
       which users contract and pay for a certain  allocation  of
       system resources..

       When  the  class scheduler daemon is started, it loads the
       database into memory, creates an initial array  of  clocktick
 integers used by the kernel, and writes this array to
       the kernel. Along with the array,  the  daemon  gives  the
       kernel  the  time  interval  during  which integers in the
       array are to be decremented. Then the  daemon  alternately
       sleeps  and wakes up to refresh the array. The daemon calculates
 the total number of clock ticks  in  the  interval
       during which it sleeps by using the following formula:

       interval_in_seconds   *   clock_ticks_per_second   *  number_of_CPUs

       The deamon then allocates the total number of clock  ticks
       among classes according to the specified percentages, creates
 the array of integers, and writes the  array  to  the
       kernel.  Should  the  daemon terminate or fail to wake up,
       the kernel automatically disables class  scheduling  after
       twice the specified time interval has passed. If this happens,
 processes belonging to scheduling classes  then  run
       freely, no longer subject to their CPU percentage restrictions.

       Class scheduling always operates in the context of a  soft
       partition,  which  is currently mapped to a processor set.
       (See processor_sets(4).)  This means that "number_of_CPUs"
       in  the preceding formula represents the number of CPUs in
       the partition associated with the class database. If userdefined
  partitions do not exist on the system, all system
       CPUs belong to the default partition  (processor  set  0),
       and  the  system can have only one active database and one
       instance of a class scheduler daemon. If system CPUs  have
       been  allocated  into  different  partitions, you have the
       option of setting up class scheduling on one  or  more  of
       the available partitions.

       By default, the class_admin utility operates on the system
       default partition; however, the utility includes the  setp
       subcommand to change partition context for subsequent subcommands.
   For  each  partition  where  you  want   class
       scheduling to be implemented, you must create at least one
       class scheduling database  and  enable  class  scheduling.
       See class_admin(8) for details.

       A  process  may be represented in a class database by members
 in more than one class. For  example,  the  group  ID
       representing  the group staff might be a member of class A
       and the user ID representing the user  guest  might  be  a
       member  of  class B. If user guest belongs to group staff,
       the user belongs to two classes. In such cases, the  class
       containing  the most restrictive type of ID applies to the
       process.  For the example just described, user ID is  more
       restrictive  than  group ID, so the process for user guest
       would execute in class B. When  member  types  are  ranked
       from  least  to most restrictive, the order is as follows:
       group ID, user ID, session ID, process group  ID,  process

       Class  scheduling  is  subject to the following limits, as
       defined in the class.h header file: Maximum of  partitions
       (class database/daemon pairs) per system: 100 Maximum number
 of classes per database: 100 Maximum number of members
       across all classes: 2500 Maximum number of characters in a
       class database pathname (for save and  load  subcommands):
       80 Maximum number of characters in a class name: 20

       Class scheduling is subject to the following restrictions:
       You must be superuser to invoke the  class_admin  utility.
       Users cannot use the runclass command to raise an application's
 priority above what it would otherwise have through
       definitions  in the class database. In other words, a user
       who is a member of a class entitled to a certain  percentage
  of  CPU time cannot use the runclass command to start
       applications at a higher priority than what  the  user  is
       entitled  to.   For most operations that applications perform
 by using routines in the libclass library, root  permission
 is required.

   Using Class Scheduling    [Toc]    [Back]
       To  implement  class  scheduling,  you must first create a
       database file and populate  the  file  with  one  or  more
       classes.   You assign each class a percentage of the total
       CPU time available.  One or more applications or groups of
       applications  can be assigned to a class, specified by the
       appropriate identifying number, such as  a  GID,  UID,  or
       PID. Any identifiers that are temporary, such as a PID, do
       not persist across a reboot and cease to exist when a task
       is  completed.   Therefore,  they  have no effect when the
       system or task is restarted. For this reason, the  members
       you add to the database when first creating it are usually
       user and group identifiers.

       After the database is established, you can start the class
       scheduling  daemon to put the CPU access restrictions into
       effect.  The class_admin utility has subcommands that  let
       you  review  classes,  change members and CPU percentages,
       delete members or entire classes, and review assigned  CPU
       percentages against actual use. You can invoke the utility
       either interactively or by using a script.

       Once a class scheduling database  is  configured  and  its
       corresponding  daemon  enabled, you can start applications
       in any of the  existing  classes  by  using  the  runclass
       command.  This  allows  you to indirectly add entirely new
       processes to a class. It also allows  you  to  temporarily
       lower  or  (if  you have superuser privilege) increase the
       CPU percentages for processes that otherwise startup in  a
       class  with  a  different CPU percentage. For example, you
       might set a value for interactive operations that is  much
       higher  than  background  processes such as print daemons.
       If it is later necessary to  temporarily  use  the  higher
       value for a particular print job, you can use the runclass
       command to execute the lpd daemon in  the  same  class  as
       interactive operations. After the print job has completed,
       the class_admin delete subcommand can be  used  to  remove
       the process identifier for lpd from the class.

       The  following  sections  suggest a systematic approach to
       using class scheduling, although you can  use  it  equally
       well to quickly fix a CPU resource sharing problem.

   Planning CPU Resource Allocation    [Toc]    [Back]
       How  you allocate CPU resources will depend on your system
       environment and which 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 backup 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,  such  as  in  process-control  applications,  that
       should take priority over interactive processes. 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.

       While thinking about CPU resource allocation, you need  to
       decide  whether  you  should use class scheduling, a userdefined
 processor set, or both on your system. CPUs  in  a
       user-defined  processor  set cannot be used by any process
       that is not explicitly run on that  processor  set.  Sometimes
  reserving  specific  CPUs  for  use only by certain
       applications, such as those doing  realtime  process  control,
 is warranted. For critical applications, a processor
       set can provide a better guarantee of immediate CPU availability
  than  class scheduling if the system load is high
       and load patterns are not always predictable. When running
       selected  applications in a non-default processor set, you
       trade off potential waste of CPU  resources  to  guarantee
       that  CPUs  are  available for the applications running in
       that processor set. Setting  "soft"  CPU  percentages  for
       scheduling  classes  allows  the  kernel to apply only the
       idle CPUs  in  the  processor  set  for  which  the  class
       database  was  created. The kernel cannot use idle CPUs in
       one processor set to ease CPU contention by processes running
 in another processor set. This means that the performance
 of less critical applications might not  be  acceptable
  after  they  are restricted to the reduced number of
       CPUs in the default processor set. Using class  scheduling
       in  a  processor  set  to better control CPU access is not
       likely to help when there are simply too few  CPUs  to  do
       the required amount of work.

       Sometimes  your  site might be running an application that
       incorrectly spawns large numbers of threads  that  immediately
  grab more CPU resources than the application needs.
       Until the application can be corrected, you can  define  a
       new processor set, populate it with a subset of the system
       CPUs, and use the runon command to start  the  application
       in  the new processor set. In this case, it might or might
       not be worthwhile to use class scheduling in  the  default
       processor  set  where  remaining  applications are run and
       interactive user processes are running.

       If your intention is simply to apply  a  more  appropriate
       allocation  of  CPU  resources  than the kernel applies by
       default, try class scheduling by itself  (on  the  default
       processor set while it contains all system CPUs) to see if
       this approach accomplishes what you want. Consider  defining
 and using an additional processor set in order to meet
       the requirements of  applications  with  unusual  requirements.

   Steps for Setting Up and Using Class Scheduling    [Toc]    [Back]
       The  usual  process  for setting up class scheduling is as
       follows: Decide how you want to allocate the CPU resources
       (decide  on  class groupings of users and tasks).  Use the
       class_admin utility's subcommands to set up  and  maintain
       the class database: Configure the database. For this step,
       you specify: whether you want a  default  class  for  processes
  (other  than those for UID 0) that are not members
       of the classes you define, whether you want hard  or  soft
       enforcement  of  CPU  percentages,  and how frequently the
       scheduler checks CPU usage by classes.  Create classes and
       add  any  users  and groups to classes by using the create
       and add subcommands.  When creating classes, keep in  mind
       the  20-character  restriction on class names and the fact
       that CPU percentages for all your classes cannot add up to
       more than 100 percent.  Verify class entries with the show
       subcommand.  Use the save  subcommand  to  write  database
       entries to /etc/class/filename.  Keep in mind the 80-character
 pathname restriction if you prefer your  own  directory
  locations  and  names  for class databases.  Use the
       enable subcommand to start the scheduler.

              Applications are usually  added  to  classes  after
              class  scheduling  is enabled by using the runclass
              command,  which  is  not  a   subcommand   in   the
              class_admin  utility.   Use the stats subcommand to
              check target and actual CPU usages for the  different

       The  following  example  shows  an interactive class_admin
       session that sets up  two  class  databases  (daytime  and
       nighttime)  for  the  default  partition. In this example,
       both  databases  have  the  same  two  classes   (interactive_users
  and  batch_jobs), however, the CPU percentages
       for these classes and  the  time  interval  for  resetting
       class  usage  are set differently. After the two databases
       are created and saved to disk,  the  daytime  database  is
       loaded  into  memory, the scheduler daemon is enabled, and
       runtime statistics are checked: # 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
       (yes/no) [no]:

       Enforce  class  scheduling when the CPU is otherwise idle?
       (yes/no) [yes]: no

       How often do you want the system  to  reset  class  usage?
       Enter number of seconds (1): class> show Configuration:
        -Processes not explicitly defined in the database are not
         class scheduled.
        -If the processor has some  idle  time,  class  scheduled
       processes are
         allowed to exceed their cpu percentage.
        -The  class  scheduler will check class CPU usage every 1

       current      partition:      0      current      database:
       /etc/class/part.default Class scheduler status: disabled


       class>  create interactive_users 50 interactive_users created
  at  50%  cpu  usage  class>  create  batch_jobs   10
       batch_jobs  created  at  10% cpu usage class> add interactive_users
 uid 234 457 235 uid 234 457 235 added to interactive_users.
   class>  save  /etc/class/daytime  database
       /etc/class/daytime saved class>  modify  interactive_users
       10  interactive_users  targeted at 10% usage class> modify
       batch_jobs 50 batch_jobs targeted at 50% class>  configure
       Shall  processes that have not been explicitly assigned to
       a defined class be assigned to a 'default'  class?   Enter
       (yes/no) [no]:

       Enforce  class  scheduling when the CPU is otherwise idle?
       (yes/no) [yes]: no

       How often do you want the system  to  reset  class  usage?
       Enter    number    of   seconds   (1):   5   class>   save
       /etc/class/nighttime database  /etc/class/nighttime  saved
       class> load /etc/class/daytime

       The following warning and prompt is displayed because this
       session   has   not   saved    any    changes    to    the
       /etc/class/part.default  file,  which  is  the database to
       which context was set at the beginning of the  interactive
       session.  However,  all  permanent  changes  were saved to
       databases with more meaningful  names,  and  there  is  no
       intention to put the /etc/class/part.default database into
       use. Therefore, the utility is told to continue  with  the
       load  operation:  current  database modified and not saved
       load new database anyway?  (yes/no)  [yes]:  yes  database
       /etc/class/daytime  loaded  class>  enable class scheduler
       enabled class>

       In another terminal window, the runclass command  is  used
       to  start  one  or  two  low-priority  applications in the
       batch_jobs class. For example: # runclass batch_jobs  program_name

       Then,  runtime  statistics can be checked in the window of
       the class_admin session: class> stats

            Class scheduler status: enabled

            class name        target percentage       actual percentage
            interactive_users                   50%
       40.0%            batch_jobs                            10%
       9.0% class>

       While the database is loaded and class scheduling enabled,
       you can modify the database  dynamically  to  achieve  the
       results  you want by using the configure, change, add, and
       destroy subcommands, interspersed with the show and  stats
       subcommands   to   check   results.  Enter  a  final  save
       /etc/class/filename subcommand when you are satisfied with
       your modifications.

       When run in interactive mode, the class_admin utility asks
       on exit or quit whether you want to write database changes
       to  disk if you have not explicitly saved them during your
       session. If the utility is run from a script, any  changes
       to the class database are saved to disk automatically. The
       changes that are saved to disk do not include  changes  in
       class  membership  for temporary identifiers (process IDs,
       process group IDs, and session IDs) because these  do  not
       persist across system reboots. It is always a good idea to
       do explicit save operations when you intend to  create  or
       modify class databases that have non-default names or that
       are stored in directories other than /etc/class.

       You also have the programming option of using the  class_*
       routines in the libclass library to do the operations discussed
 in this section.

FILES    [Toc]    [Back]

       Default directory and name for the class database  in  the
       system  default  partition  (processor  set  0).   Default
       directory and name for a class database in a  user-defined
       partition  (processor  set  number  2 and higher).  Header
       file defining the prototypes for routines in the  libclass
       library,  as  well as the type, structure, and other kinds
       of definitions used by those  routines.   Class  scheduler

SEE ALSO    [Toc]    [Back]

       Commands: runclass(1), class_admin(8)

       Files: processor_sets(4)

       Functions:          class_add(3),         class_change(3),
       class_change_name(3), class_close(3),  class_configure(3),
       class_create(3),            class_database_file_exists(3),
       class_database_modified(3),        class_database_name(3),
       class_delete(3),    class_destroy(3),    class_disable(3),
       class_get_class_members(3),          class_get_classes(3),
       class_get_config_stats(3),         class_load_database(3),
       class_open(3),                  class_restore_database(3),

[ Back ]
 Similar pages
Name OS Title
class_get_classes Tru64 get classes for a class scheduling database
class_change Tru64 change the allotted resources of an existing scheduling class
sched_setscheduler Tru64 Sets the scheduling policy and scheduling parameters of the specified process (P1003.1b)
pthread_getschedparam Tru64 Obtains the current scheduling policy and scheduling parameters of a thread
pthread_setschedparam Tru64 Changes a thread's scheduling policy and scheduling parameters
sbuf.prot IRIX interface for derived classes
VkCmdRegistry IRIX registry for named command classes
UNIVERSAL IRIX base class for ALL classes (blessed references)
Class::Struct IRIX declare struct-like datatypes as Perl classes
iflHashTable IRIX base classes from which hash table implementations may be derived
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service