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.

     Miser, given a job and its resource request, a tuple of time/space,
     searches through a time/space pool it manages to find an allocation that
     fist fits the job's requests.  A successful allocation, called the
     schedule, is a tuple consisting of a start and end time and the resources
     alloted 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 in the vectors 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
     midnight of UTC (see gettimeofday(3B)). The duration of the system vector
     defines how far into the future relative to midnight of CTU 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 defintion 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 8pm and 4am and manged no resources between 4:00am and
     8:00pm would consist of two resource tuples, the first with a start time
     of 0 and end time of 4 hours and the second with a start time of 20 hours
     and end time of 24 hours.  The actual values of the resource vector
     entries, depend on the value of the current time. So if the current time
     was 4pm, then the entries corresponding to 4pm through 8pm would reflect
     that there was no available space; the entries between 8pm and 4am would
     reflect that the resource vector had 10 CPUs and 1g of memory to
     allocate; and between 4am and 4pm 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 therefore, 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
     only policy supplied with miser is the "default" policy which is a first
     fit policy. NQE/NQS use a different policy to support NQE/NQS
     requirements.

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