miser(4) miser(4)
miser - configuration files
The configuration of the miser(1) Queues defines the resources allocated
to the miser system. The configuration of miser(1) involves two steps.
The first is to enumerate all the queues that will be part of the
miser(1) system, and the second is to define the queues. The enumeration
of the queues is done in the miser configuration file. The definition of
the queues is done in the queue definition files.
Each miser(1) system requires that a system queue be defined. The system
queue definition defines the maximum resources available to any other
queue's definition.
MISER CONFIGURATION FILE [Toc] [Back] The miser configuration file is a list of the queue names and the
location of each queue definition file.
QUEUE system /usr/local/miser/config.system
QUEUE physics /usr/local/miser/config.physics
Each miser configuration file must include a definition for the system
queue. The system queue is identified by the queue name "system".
Commands are newline terminated, characters following the comment
delimiter are '#' are ignored, and case matters.
The valid tokens are:
QUEUE [qname] [file pathname]
The queue name is used to identify the queue when using any
interface to miser. The queue name must be between 1 and 8
characters long. The queue name system is used to designate the
system queue.
QUEUE DEFINITION FILE [Toc] [Back] The queue definition file consists of a header specifying the policy of
the queue, the number of resource segments, and the quantum used by the
queue. If the quantum of any queue is different from the system queue
quantum, the queue definition file is rejected.
# This queue definition file defines a queue using the policy
# named "default", has a quantum of 20 seconds, and has 3
# elements to the vector definition. The start and end times
# of each tuple are in quanta not in seconds. The first segment
# defines a resource tuple beginning at 00:00 and ending at
# 00:50 with 50 CPUs and 100 megabytes of memory. The second
Page 1
miser(4) miser(4)
# segment defines a resource tuple beginning 00:51.67 and ending
# at 01:00 with 50 CPUs and 100 megabytes. The third segment
# defines a resource tuple begining at 01:02.00 and ending at
# 01:03.33 also with 50 CPUs and 100 megabytes of memory.
POLICY default
QUANTUM 20
NSEG 3
SEGMENT [Toc] [Back]
NCPUS 50
MEMORY 100m
START 0
END 150
SEGMENT [Toc] [Back]
NCPUS 50
MEMORY 100m
START 155
END 185
SEGMENT [Toc] [Back]
NCPUS 50
MEMORY 100m
START 186
END 190
Commands are newline terminated, characters following the comment
delimiter are '#' are ignored, and case matters.
Each new segment must begin with the token SEGMENT and must have the
number of CPUs, memory and wall clock time specified at a minimum.
The valid tokens are
POLICY name
The name of the policy that will be used to schedule applications
submitted to the queue. Currently, the two valid policies are:
"default", and "repack". The "default policy is the first fit
policy, where once a job is scheduled, its start and end time
remains constant. 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 miser(5).
Page 2
miser(4) miser(4)
QUANTUM time
The size of the quantum. The time is specified in seconds.
NSEG number
The number of resource segments.
SEGMENT [Toc] [Back]
Defines the beginning of a new segment of the vector definition.
START number of quanta from 0
The number of quanta from 0 (defined to be CTU) that the segment
begins at.
END number of quanta from 0
The number of quanta from 0 (defined to be CTU) that the segment
ends at.
The maximum acceptable END value is 259200. This represents a possible
maximum run length of two months with a 20 second quantum size ((2 months
* 30 days * 24 hours * 60 minutes * 60 seconds) / 20 seconds). The
effective maximum queue duration can be increased beyond two months by
increasing the quantum size.
NCPUS number of CPUs
The number of CPUs.
MEMORY amount of memory
The amount of memory, specified by an integer followed by an
optional unit of k for kilobyte, m for megabyte, and g for gigabyte.
If no unit is specified then the value is treated as byte.
For all the examples, the machine has 12 CPUs and 160MB memory.
EXAMPLE 1: A machine dedicated to batch scheduling with one queue, 24
hours a day.
First System Queue must be defined. The length of the system queue
defines the maximum duration of any job submitted to the system. For
this system the maximum duration for any one job can be 48 hours, so the
system vector is defined to have a duration of 48 hours.
# The system queue /usr/local/miser/system
POLICY none # System queue has no policy
QUANTUM 20 # Default quantum set to 20 seconds
NSEG 1
SEGMENT [Toc] [Back]
NCPUS 12
MEMORY 160m
START 0
END 8640 # Number of quanta (48h * 60m * 60s / 20)
Page 3
miser(4) miser(4)
Next a user queue needs to be defined.
# The user queue /usr/local/miser/physics
POLICY default # First fit, once scheduled maintains start/end time
QUANTUM 20 # Default quantum set to 20 seconds
NSEG 1
SEGMENT [Toc] [Back]
NCPUS 12
MEMORY 160m
START 0
END 8640 # Number of quanta (48h * 60m * 60s / 20)
Finally a miser configuration file must be created.
# MISER config file
QUEUE system /usr/local/miser/system
QUEUE physics /usr/local/miser/physics
EXAMPLE 2: A machine dedicated to batch scheduling, 24 hours a day
and is shared between two user groups.
Suppose we have 2 user groups, chemistry and physics. Suppose the
machine must be divided between them, in a ratio of 66% for physics and
33% for chemistry.
The system queue is identical to the one in EXAMPLE 1.
# The physics queue /usr/local/miser/physics
POLICY default
QUANTUM 20i
NSEG 1
SEGMENT [Toc] [Back]
NCPUS 8
MEMORY 120m
START 0
END 8640 # Number of quanta (48h * 60m * 60s / 20)
Now the chemistry queue:
# The chemistry queue /usr/local/miser/chemistry
POLICY default
QUANTUM 20
NSEG 1
SEGMENT [Toc] [Back]
NCPUS 4
MEMORY 40m
START 0
Page 4
miser(4) miser(4)
END 8640 # Number of quanta (48h * 60m * 60s / 20)
To restrict access to each queue, the user groups physics and
chemistry are created. The permissions on the physics queue definition
file are set to execute ONLY for group physics and the permissions on
the chemistry queue definition are set to execute only for group
chemistry.
Finally, the miser configuration file must be created:
# MISER configuration file
QUEUE system /usr/local/miser/system
QUEUE physics /usr/local/miser/physics
QUEUE chem /usr/local/miser/chemistry
EXAMPLE 3: The machine is dedicated to TS in the morning but to
batch in the evening. The evening is 8pm - 4am and the morning is
4am to 8pm.
This is the same example discussed in
miser(1).
First the system queue is defined.
# System queue
POLICY none # System queue has no policy
QUANTUM 20 # Default quantum set to 20 seconds
NSEG 2
SEGMENT [Toc] [Back]
NCPUS 12
MEMORY 160
START 0
END 720 # (4h * 60m * 60s) / 20
SEGMENT [Toc] [Back]
NCPUS 12
MEMORY 160
START 3600 # 8pm is 20hours from CTU, so (20h * 60m * 60s) / 20
END 4320
Next, the batch queue is defined.
# User queue
POLICY repack # Repacks jobs (FIFO) if a job finishes early
QUANTUM 20 # Default quantum set to 20 seconds
NSEG 2
SEGMENT [Toc] [Back]
Page 5
miser(4) miser(4)
NCPUS 12
MEMORY 160
START 0
END 720 # (4h * 60m * 60s) / 20
SEGMENT [Toc] [Back]
NCPUS 12
MEMORY 160
START 3600 # 8pm is 20h from CTU, (20h * 60m * 60s) / 20
END 4320
miser(5), miser(1), miser_submit(1), miser_jinfo(1), miser_qinfo(1),
miser_move(1), miser_reset(1).
PPPPaaaaggggeeee 6666 [ Back ]
|
