Filter
Top Products
Scheduling Constraints
together. That is to say, all of the processes in a program are either
running or suspended at the same time.
Gang scheduling is required for tightly coupled parallel programs
which communicate frequently. It becomes increasingly important as
the rate of interprocess communication increases. For example, if a
program is executing a barrier synchronization, all processes must be
scheduled before the barrier completes.
Effective scheduling of parallel programs requires that user access
through commands such as rsh, rlogin and telnet is disabled.
This is carried out by the partition startup script (see Section 4.4).
general The scheduling policy supports UNIX time-sharing with load
balancing and gang scheduling. It is appropriate for a login partition
that is used for developing and debugging parallel programs.
batch The scheduling policy is determined by a batch system. It is
appropriate for partitions that are for the exclusive use of a batch
system. The batch system may run sequential or parallel programs as
it wishes but interactive use is prohibited.
7.3 Scheduling Constraints
The scheduling decisions made while gang scheduling are controlled by a number of
parameters. These parameters can be specified for individual users and for projects
(groups of users) in the access_controls table (see Section 10.2.1). Restrictions on the
partition itself are specified in the partitions table (see Section 10.2.16). The
parameters are as follows:
Priority
Each resource request is assigned a priority taken from the priority field of the
access_controls table. The Partition Manager schedules resource requests in order
of priority. Where a number of requests are queued with the same priority, they are
scheduled by order of submission time. The submission into the queue of a high priority
request may cause existing low priority jobs to be suspended. Changing the priority of a
request requires administrator privileges.
Maximum Number of CPUs
An upper limit can be set on the number of CPUs that may be allocated to a user or
project at any point in time. Requests that take the usage count for the user or project
above this limit are blocked. Requests for more CPUs than the limit on a user or project
are rejected.
7-2 RMS Scheduling