Filter
Top Products
RMS Management Functions
A further partition, the root partition, is always present. It includes all nodes. It does
not have a scheduler. The root partition can only be used by administrative users (root
and rms by default).
2.4.2 Scheduling
Partitions enable different scheduling policies to be put into action. On each partition,
one or more of three scheduling policies can be deployed to suit the intended usage:
1. Gang scheduling of parallel programs, where all processes in a program are
scheduled and de-scheduled together. This is the default scheduling policy for parallel
partitions.
2. Regular UNIX scheduling with the addition of load balancing, whereby the user can
run a sequential program on a lightly loaded node. The load may be judged in terms
of free CPU time, free memory or number of users.
3. Batch scheduling, where the use of resources is controlled by a batch system.
Scheduling parameters such as time limits, time slice interval and minimum request
size are applied on an individual partition basis. Default priorities, memory limits and
CPU usage limits can be applied to users or projects to tune the partition’s workload. For
details see Chapter 6 (Access Control, Usage Limits and Accounting) and
Chapter 7 (RMS Scheduling).
The partition shown in Figure 2.5 has its CPUs allocated to five parallel jobs. The jobs
have been allocated CPUs in two different ways: jobs 1 and 2 use all of the CPUs on each
node; jobs 3, 4 and 5 are running with only one or two CPUs per node. RMS allows the
user to specify how their job will be laid out, trading off the competing benefits of
increased locality on the one hand against increased total memory size on the other.
With this allocation of resources, all five parallel programs can run concurrently on the
partition.
Figure 2.5: Distribution of Processes
3
2
1
0
7
6
5
4
11
10
9
8
15
14
13
12
3
2
1
0
7
6
5
4
0
0
1
1
2
2
3
3
1
0
4
4
3
2
5
5
5
4
6
6
7
6
7
7
16Nodes
4CPUs
Job1
Job2
Job3
Job4
Job5
2-8 Overview of RMS