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

  man pages->IRIX man pages -> miser (5)              


MISER(5)							      MISER(5)

NAME    [Toc]    [Back]

     miser, batch - The	Miser Resource Manager

DESCRIPTION    [Toc]    [Back]

     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 policyrelated
 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    [Toc]    [Back]

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

									PPPPaaaaggggeeee 2222
[ Back ]
 Similar pages
Name OS Title
miser IRIX Miser resource manager
miser_qinfo IRIX query information on miser queues, queue resource status, and list of jobs scheduled against a queue
pool_prime NetBSD resource-pool manager
pool_put OpenBSD resource-pool manager
pool_sethiwat OpenBSD resource-pool manager
pool_setlowat OpenBSD resource-pool manager
pool NetBSD resource-pool manager
pool_setlowat NetBSD resource-pool manager
pool_sethiwat NetBSD resource-pool manager
sharemgr IRIX shared resource manager
Copyright © 2004-2005 DeniX Solutions SRL
newsletter delivery service