batch man page on IRIX

Man page or keyword search:  
man Server   31559 pages
apropos Keyword Search (all sections)
Output format
IRIX logo
[printable version]



MISER(5)							      MISER(5)

NAME
     miser, batch - The Miser Resource Manager

DESCRIPTION
     Miser is a resource management facility with a batch process scheduling
     component.	 This component allows a system administrator to balance
     interactive and batch load on a machine without static partitioning.
     Miser provides deterministic batch scheduling associated with static
     partitioning without the wasted resources that result from static
     partitioning.  Idle resources are always available for use regardless of
     ownership, but are reclaimed on demand as necessary.

     Miser schedules applications with known time and space requirements.  The
     user level component of miser, the daemon, generates a non-conflicting
     schedule of applications.	The schedule is said to be non-conflicting
     because at no point in the schedule are the resources over-subscribed. An
     application scheduled by miser is scheduled to begin running at a
     particular point in time and then to run without preemption until the end
     time has been reached.  The kernel component uses the schedule to
     determine what resources an application has access to and when to
     actually schedule an application to run.  The applications are said to be
     scheduled in a batch fashion.

     Given a job and its resource request, a tuple of time/space, Miser
     searches through a time/space pool, until it manages to find an
     allocation that fits the job's requests.  A successful allocation, called
     the schedule, is a tuple consisting of a start and end time and the
     resources allotted to the application during the interval defined.	 These
     resources are guaranteed by the kernel during the schedule.

     Miser manages the time/space pool using a hierarchy of resource vectors
     indexed by time, using a system-wide quantum.  All vectors are of equal
     size. Each entry specifies a set of resources allocated to the vector: a
     number of CPUs and an allocation of physical memory.  The system vector
     defines the set of resources allocated to Miser; all other vectors
     allocate their resources from the system vector.  Associated with each
     vector is a vector definition (to allocate new entries as time advances),
     a set of jobs scheduled against the resources of the vector, a policy
     module that controls the scheduling of jobs, and miscellaneous policy-
     related data.  The collection of a resource vector and its associated
     code and data structures is called a Queue.

     The resource vector represents the time/space pool a Queue manages.  The
     length of the resource vector defines the length of the time dimension of
     the time/space pool or the duration of the time/space pool, and is
     defined to be the length of the system vector.  The resource vector's
     duration is not fixed in time, but rather represents how far into the
     future the Queue can schedule resources.  The actual amount of space
     available at any point in time is defined by the vector definition.  The
     vector definition consists of a list of resource tuples.  The resource
     tuples contain a start and end time, and a quantity of space.  The tuples
     are ordered by their start and end times and these times are relative to

									Page 1

MISER(5)							      MISER(5)

     midnight of UTC (see gettimeofday(3B)).  The duration of the system
     vector defines how far into the future relative to midnight of UTC the
     last tuple's end time can be. The duration of the vector definition is
     the time between time 0 and the end time of the last tuple.  If the
     duration is greater than the duration of the system vector, the vector
     definition is truncated.  If the vector definition is shorter, then it is
     repeated.	If the duration of the vector definition does not perfectly
     divide into the system vector's duration, and is smaller, then the last
     repetition of the vector definition is truncated.

     Given that the origin for time is 00:00 Thursday Jan 1st, it is possible
     to construct vector definitions for weeks, days or parts of days by
     creating appropriate resource tuples.  Note, time zero is time zero at
     GMT adjusted for timezone difference, and daylight savings.  For example,
     a vector definition for a Queue that managed 10 CPUs and 1 gigabyte of
     memory between 8:00pm and 4:00am and managed no resources between 4:00am
     and 8:00pm would consist of two resource tuples, the first with a start
     time of 00:00 hours and end time of 04:00 hours, and the second with a
     start time of 20:00 hours and end time of 00:00 hours.  The actual values
     of the resource vector entries, depend on the value of the current time.
     So if the current time was 4:00pm, then the entries corresponding to
     4:00pm through 8:00pm would reflect that there was no available space;
     the entries between 8:00pm and 4:00am would reflect that the resource
     vector had 10 CPUs and 1g of memory to allocate; and between 4:00am and
     4:00pm there were no resource available. In other words, the value of the
     0 entry of the resource vector does not correspond to time 0 of the
     vector definition.	 If the system vector was a week long, then the
     resource vector definition would be repeated seven times. The Queue would
     be able to schedule an application up to a week in advance of its
     execution time.

     The policy module defines the way in which a block of time/space is
     searched to satisfy the resource request made by the application.	The
     two policies supplied with miser are the "default" and "repack" policy.
     The "default policy is the first fit policy.  In this policy once a job
     is scheduled, its start and end time remains constant.  The event of an
     earlier job finishing ahead of schedule does not have any effect on the
     start/end time of the future scheduled jobs.  On the other hand the
     "repack" policy does as its name implies.	Each time any job ends on a
     queue with a repack policy the entire job schedule is reevaluated and
     updated.  When machine resources are freed due an executing job's early
     termination, the repack policy will attempt to reschedule queued jobs,
     pulling them ahead in time.  While repacking endeavors to maintain the
     FIFO order of queued jobs, a higher priority is given to the optimal
     utilization of machine resources.	The actual start and end times of a
     job in a queue with a repack policy can potentially be earlier than its
     initially reported start and end times.

SEE ALSO
     miser(1), miser_submit(1), miser(4), miser_jinfo(1), miser_qinfo(1),
     miser_move(1), miser_reset(1).

									Page 2

[top]

List of man pages available for IRIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net