IBM Power7 Optimization And Tuning Manual page 79

However, after the initial configuration, the setup might not stay static. Numerous operations
take place, such as:
Reconfiguration of existing LPARs with new profiles
Reactivating existing LPARs and replacing them with new LPARs
Adding and removing resources to LPARs dynamically (DLPAR operations)
Any of these changes might result in memory fragmentation, causing LPARs to be spread
across multiple domains. There are ways to minimize or even eliminate the spread. For the
first two operations, the spread can be minimized by releasing the resources that are currently
assigned to the deactivated LPARs.
Resources of an LPAR can be released by running the following commands:
chhwres -r mem -m <
chhwres -r proc -m <
The first command frees the memory and the second command frees cores.
When all of the partitions are inactive, there is another way to clear the resources of all of the
existing configurations before you create a configuration. In this situation, all the resources of
all the partitions can be cleared from the HMC by completing the following steps:
1. Shut down all partitions.
2. Create the all-resources partition.
3. Activate the all-resources partition.
4. Shut down the all-resources partition.
5. Delete the all-resources partition.
Fragmentation because frequent movement of memory or processor cores between partitions
is avoidable with correct planning. DLPAR actions can be done in a controlled way so that the
performance impact of resource addition or deletion is minimal. Planning for growth helps
alleviate the fragmentation that is caused by DLPAR operations. Knowing the LPARs that
must grow or shrink dynamically, and placing them with LPARs that can tolerate nodal
crossing latency (less critical LPARs), is one approach to handling the changes of critical
LPARs dynamically. In such a configuration, when growth is needed for the critical LPAR, the
resources that are assigned to the non-critical LPAR can be reduced so that the critical LPAR
can grow.
Affinity groups (introduced in the 730 firmware level)
PowerVM firmware 730 and later has support for affinity groups that can be used to group
multiple LPARs to place (allocate resources) within a single or a few domains. On the Power
795 with 32 cores in a book, the total physical core resources of an affinity group are not to
exceed 24/32 cores or the physical memory that is contained within a book.
This affinity group feature can be used in multiple situations:
LPARs that are dependent or related, such as server and client, and application server
and database server, can be grouped so they are in the same book.
Affinity groups can be created that are large enough such that they force the assignment
of LPARs to be in different books. For example, if you have a two-book system and the
total resources (memory and processor cores) assigned to the two groups exceeds the
capacity of a single book, these two groups are forced to be in separate books. A simple
example is if there is a group of partitions that totals 14 cores and a second group that
totals 20 cores. Because these groups exceed the 32 cores in a 795 book, the groups are
placed in different books.
system_name
> -o r -q <
system_name
> -o r --procunits <
num_of_Mbytes
> --id <
number
> --id <
Chapter 3. The POWER Hypervisor
lp_id
>
lp_id
>
63