Locality-Optimized Resource Alignment

10
Configuring vPars for LORA
Considerations for memory granule size
Memory for vPars instances is allocated only in multiples of the memory granule size. The granule
size can be different for interleaved memory and local memory. Default granule sizes are established
when a server complex is shipped from the factory. The defaults can be changed by use of the
vparenv command, or by adding options to the command that creates the very first vPars instance.
A small granule size permits the greatest flexibility in dividing the memory resources in an nPartition
for assignment to vPars instances. However, a small granule size limits the size of contiguous
physical memory objects, which are useful to increase the performance of I/O drivers, and can result
in longer boot times. Also, there is a limit on the total number of granules that can be created. The
large granule size is more efficient, but it means that the quantum of memory allocation is large.
Under the LORA configuration guidelines, an nPartition has seven times as much local memory as
interleaved memory. Therefore, it is reasonable that the granule size for local memory is larger than
the granule size for interleaved memory. For example, the local memory granule size could be four
times larger or eight times larger than the interleaved memory granule size.
An alternative strategy would be to skip interleaved memory altogether for extremely small vPars
instances. For example, a vPars instance with only 2 GB of memory could be configured with 100%
local memory, instead of giving it 256 megabytes of interleaved memory, which would require a
granule size at least that small.
In the examples that follow, it is assumed that the memory granule sizes have been established so that
the requested memory allocations are an integral multiple of the relevant granule size.
Creating new vPars instances
In this section, we'll assume that an nPartition has already been configured in accordance with the
LORA guidelines and will now be configured for vPars. There are two important sub-cases: dividing
the nPartition into a given number of vPars instances of equal size, and establishing a set of vPars
instances each with its own processor and memory requirements.
In either case, the goal of the configuration is to create vPars instances where the cores and local
memory are drawn from the minimal set of localities. If the I/O can also come from those same
localities, that is a bonus, but might not be possible because of the locations of the needed I/O
adapters. The enhancements introduced with vPars version A.05.05 can take account of the location
of I/O adapters when assigning processor cores to vPars instances.
The LORA configuration procedure is a refinement of the general vPars configuration procedure
described in the
HP-UX Virtual Partitions Administrator's Guide. That reference should be consulted for
details not discussed in this paper.
We illustrate the procedure with an nPartition consisting of cells 1, 2, and 3 in an HP Integrity rx8640
server with 64 GB of memory on each cell. If the nPartition is configured according to the LORA
guidelines, each cell would have 56 GB of local memory and would contribute 8 GB to the 24 GB of
ILM in the partition. The available processor and memory resources are shown in the following
diagram: