How Access Controls are Applied
parallel priority = 5
rcontrol create access_control = default class = project partition = \
parallel priority = 0 memlimit = 256
name class partition priority maxcpus memlimit
design project parallel 5 Null Null
default project parallel 0 Null 256
Requests submitted by Jim, Mary and John run at priority 5, causing other users’ jobs to
be suspended if running. These requests are not subject to CPU or memory limits.
Requests submitted by other users run at priority 0 and are subject to a memory limit of
256MB per CPU. Note that on a system with 4 CPUs and 4GB of memory per node, it
would be necessary for each node to have at least 5GB of swap space to ensure that jobs
submitted by the design group were not blocked by other users (see Section 7.4.2 for
details).
In this example, we have not set the maxcpus limit as we do not mind how many CPUs
the users allocate. This limit could be set if there were two groups of users of equal
priority and you wanted to bound the number of CPUs that each could allocate.
6.4 How Access Controls are Applied
The rules governing memory limits, priority values and CPU usage limits are described
in more detail in the following sections.
6.4.1 Memory Limit Rules
Memory limits for a resource request are derived by applying the following rules in
sequence until an access control record with a memory limit is found.
1. The root user has no memory limits.
2. If the user has an access control record for the partition, the memory limit in the
access control record applies.
3. The access control record for the user’s current project determines the memory limit.
4. The access control record for the default project determines the memory limit.
Having selected an access control record, the memory limit for the program is set by the
value of its memlimit field. A null value disables memory limits. Other values are
interpreted as the memory limit in megabytes for each CPU. A process with one CPU
6-4 Access Control, Usage Limits and Accounting