How PRM manages CPU resources for real-time processes

Although PRM is designed to treat processes fairly based upon their assigned shares, PRM does not restrict real-time processes. Real-time processes using either the POSIX.4 real-time scheduler (rtsched) or the HP-UX real-time scheduler (rtprio) keep their assigned priorities because timely scheduling is crucial to their operation. Hence, they are permitted to exceed their group’s CPU share and cap. The CPU resources they use are charged to their groups. Thus, they can prevent other processes in their groups from running.

Hyper-Threading

Hyper-Threading, available starting with HP-UX 11i v3 (B.11.31), enables you to use multiple execution threads per core. Each execution thread is a logical CPU.

PRM supports the Hyper-Threading feature for PSET PRM groups. When PRM creates new PSETs, they inherit the Hyper-Threading state the system had before PRM was enabled. You can override the inherited state, specifying the desired state in the PRM configuration using the PSET_ATTR field in group records. For more information, see the section “Group/CPU record syntax” (page 55).

PRM sets the Hyper-Threading state for the default PSET, where FSS PRM groups are created, to optimize workload performance.

NOTE: Do not change the value of a PSET’s LCPU attribute, using either psrset or kctune, while PRM is running.

Multiprocessors and PRM

PRM takes into account architectural differences between multiprocessor (MP) and single-processor systems.

In the case of memory management, Hewlett-Packard multiprocessor systems share the same physical address space. Therefore PRM memory management is the same as on a single-processor system.

However, in the case of CPU resource management, PRM makes accommodations for MP systems. The normal HP-UX scheduling scheme for MP systems keeps the CPU load average at a uniform level across the cores. PRM tries to even the mix of FSS PRM groups on each available CPU. (With Hyper-Threading disabled, each core is seen as a CPU. With Hyper-Threading enabled, each core can be seen as multiple, logical CPUs.) This is done by assigning each process in an FSS PRM group to a different CPU, stepping round-robin through the available CPUs, with the CPUs being cores or logical CPUs depending on whether Hyper-Threading is enabled. Only processes that can be run or processes that are likely to run soon are actually assigned in this manner.

For example, on a two-way MP system with Hyper-Threading disabled, FSS PRM Group1 has two active processes A and B, and FSS PRM Group2 has two active processes C and D. In this example, PSET PRM groups are not configured. PRM assigns process A to the first core, process B to the second core, process C to the first core, and finally process D to the second core—as shown in Figure 7 (page 26).

How PRM manages CPU resources 25