miser_submit(1)
miser_submit - submit a job to a miser queue
As shipped in IRIX 6.5.22. Last changed in IRIX 6.5.7.
NAME miser_submit - submit a job to a miser queue SYNOPSIS miser_submit -q qname -f file command | -h miser_submit -q qname -o c=CPUs,m=mem,t=time[,static] 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 will do a first fit of each segment of the schedule in the specified queue. DISPLAY The format of the schedule returned by miser_submit is a table that lists: JOBID 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 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 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 The completion time is when Miser has scheduled the job to terminate. MLT Multiple of CPUs allowed by the submitter for scheduling flexibility, if total cpus requested not available. See miser_submit(4). PRI The priority is a field provided for use by scheduling policies (to be implemented). 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. 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[,static] 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 bytes. 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 scheduled. -f file This file specifies a list of resource segments. Using the file allows greater control over the scheduling parameters of a particular job. -h Prints the command's usage message. 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(1), miser(4), miser(5), miser_jinfo(1), miser_kill(1), miser_move(1), miser_qinfo(1), miser_reset(1), miser_submit(4).