Locality-Optimized Resource Alignment
17
Figure 6. Allocations after the CPU migration operations
CPU
5
CPU
6
CPU
7
CPU
2
CPU
3
CPU
4
CPU
5
CPU
7
CPU
0
CPU
1
CPU
4
dog
CPU
6
CPU
2
CPU
4
CPU
7
elk
fox
CPU
6
CPU
5
CPU
3
cow
CPU
1
CPU
0
CPU
3
CPU
0
CPU
2
CPU
1
It is also possible to migrate memory along with the processor cores, but only for the memory that was
specifically designated as floating memory. If 1 GB of memory from cell 2 in the vPars instance cow
had been designated as floating memory, it could be migrated to instance dog with the following pair
of commands:
vparmodify -p cow -d cell:2:mem::1024:floating
vparmodify -p dog -a cell:2:mem::1024:floating
Summary of vPars configuration rules
The rules for configuring vPars for LORA are simple:
• Draw resources for each vPars instance from the minimal number of distinct localities
• If the number of localities is greater than one, balance the resources across those localities
• Do the best you can with I/O devices and with instances created from leftover resources
A minor optimization, and one which also applies for 100% interleaved nPartitions, is to keep the
cores on a socket in the same instance, because they share a common cache. Keeping such cores
working together on the same application can give a small performance benefit, which is worth
realizing if the choice of cores is otherwise arbitrary. Use mpsched -K to identify the cores that
share a common socket. Similarly, mpsched –S shows which cores belong to the same proximity
set, and those should be kept together if the choice of cores is otherwise unconstrained.