Filter
Top Products
What Happens When a Request is Received
immediate The request should fail rather than block if resources are not
available immediately.
Note
The RMS scheduler attempts to allocate CPUs on a contiguous range of nodes. If
a contiguous range of nodes is not available then requests that explicitly specify
a contiguous range with the hwbcast parameter will block if the requested
CPUs cannot be allocated.
When the Partition Manager receives a request, it first checks to see if the partition has
sufficient resources. If the resources are available, the next check is on the resource
limits applied to the user and the project. If these checks fail, the request is rejected.
If the checks succeed, the scheduler attempts to allocate CPUs from those that are
currently free. If sufficient CPUs are free but allocating them would exceed the user’s
CPU usage limit, the request is marked as blocked (or, if the immediate parameter is
set, the request fails). If CPUs can be allocated, the resource request is marked as
allocated and job(s) may use the CPUs. If the request cannot be met, it is added to the
list of active requests and marked as queued. The scheduler than re-evaluates the
allocation of CPUs to all of the requests in the list.
The list of resource requests is sorted in priority order. Requests of the same priority are
sorted by submission time. When evaluating the list, the scheduler works down the
requests trying to allocate CPUs to them. The highest priority request is allocated CPUs
first except when doing so would cause the system to run out of swap space (see
Section 7.4.2).
In considering each request, the scheduler first looks at whether it has already been
allocated CPUs (a bound request). CPUs remain allocated to a request unless they are
preempted by a higher priority request, in which case the request of lower priority is
suspended together with any jobs that were running on it. If the request is not yet
bound then CPUs are allocated, if sufficient are free.
The list of requests is re-evaluated when free CPUs cannot be found for a new request,
when an existing request completes or on the expiry of the time-slice period (see
Section 7.4.3).
Consider what happens when a high priority request is submitted to a partition that is
already running jobs. If there are sufficient CPUs free (matching the constraints of the
request) then the job(s) start. If there are not enough free CPUs, the list of requests is
re-evaluated. CPUs are allocated to the high priority request and its job(s) are allowed to
start. The jobs of the lower priority requests, whose CPUs were taken for the high
priority request, are suspended. Any of the low priority jobs for which CPUs are
available continue.
7-4 RMS Scheduling