Chapter 3. The POWER Hypervisor 61
Processor bindings in a shared LPAR
In AIX V6.1 TL5 and AIX V7.1, binding virtual processors is available to an application that is
running in a shared LPAR. An application process can be bound to a virtual processor in a
shared LPAR. In a shared LPAR, a virtual processor is dispatched by the PowerVM
hypervisor. The PowerVM hypervisor maintains three levels of affinity for dispatching, such as
core, chip, and node level affinity in eFW7.3 and later firmware versions. By maintaining
affinity at the hypervisor level and in AIX, applications can achieve higher level affinity through
virtual processor bindings.
3.2.2 Page table sizes for LPARs
The hardware page table of an LPAR is sized based on the maximum memory size of an
LPAR and not what is assigned (or wanted) to the LPAR. There are some performance
considerations if the maximum size is set higher than the wanted memory:
A larger page table tends to help performance of the workload, as the hardware page table
can hold more pages. This larger table reduces translation page faults. Therefore, if there
is enough memory in the system and you want to improve translation page faults, set your
max memory to a higher value than the LPAR wanted memory.
On the downside, more memory is used for hardware page table, which not only wastes
memory, but also makes the table become sparse, which results in the
following situations:
– A dense page table tends to help with better cache affinity because of reloads.
– Less memory that is consumed by the hypervisor for the hardware page table means
that more memory is made available to the applications.
– There is less page walk time as page tables are small.
3.2.3 Placing LPAR resources to attain higher memory affinity
POWER7 PowerVM optimizes the allocation of resources for both dedicated and shared
partitions as each LPAR is activated. Correct planning of the LPAR configuration enhances
the possibility of getting both CPU and memory in the same domain in relation to the topology
of a system.
PowerVM hypervisor selects the required processor cores and memory that is configured for
an LPAR from the system free resource pool. During this selection process, hypervisor takes
the topology of the system into consideration and allocates processor cores and memory
where both resources are close. This situation ensures that the workload on an LPAR has
lower latency in accessing its memory.
When you power on partitions for the first time, power on the partitions of highest importance
first. By doing so, the partitions have first access to deallocated memory and
processing resources.
Partition powering on: Even though a partition is dependent on a VIOS, it is safe to
power on the partition before the VIOS; the partition does not fully power on because of its
dependency on the VIOS, but claims its memory and processing resources.
To Next Page
Loading...
