miser_submit(1)
miser_submit - submit a job to a miser queue
As shipped in IRIX 6.5. First release of IRIX 6.5.
NAME miser_submit - submit a job to a miser queue SYNOPSIS miser_submit -q qname -f file command miser_submit -q qname -o c=CPUs,m=memory,t=time command DESCRIPTION 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's default scheduling policy will do a first fit of each segment of the schedule in the specified queue. The schedule returned by miser(1) reflects the system's guarantee of resources; during the time specified by miser, the application will be allocated the physical resources requested. However, unless the application has requested STATIC scheduling (see miser_submit(4)), the application will be allowed to run before its designated time if there are resources available. The time it runs before it actually runs is a bonus and is not counted against the actual time it has been scheduled to run. The format of the schedule returned by miser_submit is a table that lists the batch ID, segment ID, multiple, priority, exception condition, wall clock time, completion date, CPUs allocated and memory allocated for each segment. The batch ID is used by miser(1), various miser commands, and the kernel to communicate about a specific job. It is equivalent to the process group ID. The segment ID identifies the current segment in the resource schedule list. The priority is an additional field provided for use by scheduling policies. The wall clock time is the product of CPU time and the number of CPUs. The completion date is when miser(1) has scheduled the segment to terminate. The CPUs allocated and the memory allocated list the resources reserved for that segment. OPTIONS -q qname 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. -o c=CPUs,m=mem,t=time 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 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 bytes. The time 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. -f file This file specifies a list of resource segments. Using the file allows greater control over the scheduling parameters of a particular job. RESTRICTIONS 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. SEE ALSO miser(5), miser(1), miser(4), miser_submit(4), miser_jinfo(1), miser_qinfo(1), miser_move(1), miser_reset(1).