miser_submit - submit a job to a miser queue
miser_submit -q qname -f file command | -h
miser_submit -q qname -o c=CPUs,m=mem,t=time[,static] command
The miser_submit command is used to submit a job (the command) to a
miser(1) queue. A job is an application that will be scheduled by miser.
Any application that does not change its session ID or change its process
group ID can be submitted to a miser queue. For an application to be
properly submitted to a miser(1) queue, it needs to specify its resource
schedule. A resource schedule is a list of resource specifications,
called segments, that define the resource requirements of a particular
job. A resource specification is a tuple of CPUs, memory and wall clock
time. Currently miser(1) only supports resource schedules consisting of
one segment. A segment also has additional optional fields that specify
how the job is to be scheduled. These are defined in miser_submit(4).
An application is said to be scheduled by miser(1), if it can find a
block of time/space in the resources managed by the specified queue to
schedule each segment of the application's resource schedule. If miser
can find such a block, then a schedule is returned to the user. The
schedule is a list of start and end times for each segment of the
resource schedule. The end times are guaranteed by miser, in other
words, either the application will have terminated by then or the
application will be terminated. Miser will do a first fit of each
segment of the schedule in the specified queue.
The format of the schedule returned by miser_submit is a table that
JOBID [Toc] [Back]
The batch ID is used by miser, various miser commands, and the
kernel to communicate about a specific job. It is equivalent to the
process group id.
CPU The number of CPUs allocated.
MEM The amount of memory allocated shown in bytes, kilobytes(k),
megabytes(m), or gigabytes(g).
DURATION [Toc] [Back]
The duration or the total wall clock time is the product of the CPU
time and the number of CPUs. (duration = wall clock time per CPU *
number of CPUs)
START TIME [Toc] [Back]
The starting time is when the job is going to get batch critical
priority, if running opportunistically (NON-STATIC); or will start
running if submitted as STATIC.
END TIME [Toc] [Back]
The completion time is when Miser has scheduled the job to
MLT Multiple of CPUs allowed by the submitter for scheduling
flexibility, if total cpus requested not available. See
PRI The priority is a field provided for use by scheduling policies (to
OPT The option field indicates STATIC (S) for STATIC submission, and/or
kill (K) as exception handler flag. Kill is the only exception
handling provided today.
Specifies the queue against which to schedule the application. The
user must have execute permissions on the queue definition file to
schedule an application against the resources of a particular queue.
The queue name must be a valid queue name.
Specifies a block of resources from the command line.
The CPUs must be some integer up to the maximum number of CPUs
available to the queue being scheduled against.
The memory, total job memory for all requested CPUs, consists of an
integer followed by a unit of k for kilobyte, m for megabyte or g
for gigabyte. The memory requested cannot exceed the total memory
available to the queue. If no unit is specified, the default is
The time, total wall clock time requested for the job (time = wall
clock time per CPU * number of CPUs), can be specified either by an
integer followed by a unit specifier of h for hours, m for minutes
or s for seconds, or by a string of the form hh:mm.ss. An integer
with no units is assumed to be seconds.
static is an optional argument. A job with this option enabled will
not run opportunistically. On a queue with a default scheduling
policy, it will not run earlier, even if idle resources become
available, after the job has been scheduled. On a queue with a
repack policy the entire job schedule is reevaluated and updated
each time any job ends and the job may run earlier than originally
This file specifies a list of resource segments. Using the file
allows greater control over the scheduling parameters of a
-h Prints the command's usage message.
An application scheduled by miser(1) cannot change its process group or
session ID. If it tries to, an error is returned.
An application that is scheduled by miser(1) cannot change its priority,
or bind itself to a particular CPU.
miser(1), miser(4), miser(5), miser_jinfo(1), miser_kill(1),
miser_move(1), miser_qinfo(1), miser_reset(1), miser_submit(4).
PPPPaaaaggggeeee 3333 [ Back ]