Locality-Optimized Resource Alignment for Superdome 2

13
vparcreate -N 2 -p q3 -a mem::6144
vparmodify -p 2:q3 -a socket:1/5/0:mem::21504 -a socket:1/5/1:mem::21504
vparmodify -p 2:q3 -a socket:1/5/0:cpu::3 -a socket:1/5/0:cpu::3
vparcreate -N 2 -p q4 -a mem::6144
vparmodify -p 2:q4 -a socket:1/1/0:mem::7168-a socket:1/1/1:mem::7168
vparmodify -p 2:q4 -a socket:1/3/0:mem::7168-a socket:1/3/1:mem::7168
vparmodify -p 2:q4 -a socket:1/5/0:mem::7168-a socket:1/5/1:mem::7168
vparmodify -p 2:q4 -a socket:1/1/0:cpu::1 -a socket:1/1/1:cpu::1
vparmodify -p 2:q4 -a socket:1/3/0:cpu::1 -a socket:1/3/1:cpu::1
vparmodify -p 2:q4 -a socket:1/5/0:cpu::1 -a socket:1/5/1:cpu::1
Let us compare two different ways for choosing the processor cores to be assigned to the virtual
partition q1. This is the command line given in the example:
vparmodify -p 2:q1 -a socket:1/1/0:cpu::3 -a socket:1/1/1:cpu::3
That command specifies that three cores from each of the two named sockets are assigned, and the
system is free to choose any three of the four cores on each socket. To gain more explicit control, the
following commands naming the six cores to use could have been given:
vparmodify -p 2:q1 -a core:1/1/0/0 -a core:1/1/0/1 -a core:1/1/0/2
vparmodify -p 2:q1 -a core:1/1/1/0 -a core:1/1/1/1 -a core:1/1/1/2
Since all cores on any given socket are identical, there is no need to specify the exact cores to use by
using the more detailed syntax. Unless there is some reason to pin down some particular processor
core, use the simpler socket oriented version to allow the system to identify the cores to be allocated.
Establishing virtual partitions by processor and memory requirements
Suppose you need to divide the example nPartition into virtual partitions of the following sizes:
Table 1. Specification for size of virtual partitions
Name Number of cores Amount of memory
cow 9 70 GB
dog 6 70 GB
elk 3 24 GB
fox 3 24 GB
The first virtual partition in the table, cow, requires 9 cores, so it will not fit within one or even two
localities. It will, however, fit within three localities, so it should be confined to just three localities:
spreading its resources across a fourth locality would incur additional memory latency overhead. It is
best to split the resources evenly across the three localities: this symmetry promotes the most balanced
utilization of resources. The 70 GB of memory should be allocated in the ratio ⅞
ths
local memory and
⅛
ths
interleaved memory. The 62 GB of local memory should be distributed across the three localities