When an LPAR is shut down, resources such as processors, memory, and I/O slots are not automatically released by the LPAR. The resources remain assigned to the LPAR and are then reused on the next activation (with the current configuration). In the first part of the article Resources of not activated LPARs we had already looked at this.
(Note: In the example output, we use version 1.4 of the LPAR tool, but in all cases we show the underlying commands on the HMC command line, so you can try everything without using the LPAR tool.)
The example LPAR lpar1 was shut down, but currently still occupies 100 GB of memory:
linux $ lpar status lpar1 NAME LPAR_ID LPAR_ENV STATE PROFILE SYNC RMC PROCS PROC_UNITS MEM OS_VERSION lpar1 39 aixlinux Not Activated standard 0 inactive 1 0.2 102400 Unknown linux $
The following commands for the output above were executed on the corresponding HMC hmc01:
hmc01: lssyscfg -r lpar -m ms09 --filter lpar_names=lpar1 hmc01: lshwres -r mem -m ms09 --level lpar --filter lpar_names=lpar1 hmc01: lshwres -r proc -m ms09 --level lpar --filter lpar_names=lpar1
As the output shows, the LPAR lpar1 has still allocated its resources (processors, memory, I/O adapters).
In order to understand why deactivating an LPAR does not release the resources, you have to look at the “Memory Affinity Score”:
linux $ lpar lsmemopt lpar1 LPAR_SCORE LPAR_NAME CURR PREDICTED lpar1 100 0 linux $
HMC command line:
hmc01: lsmemopt -m ms09 -r lpar -o currscore –filter lpar_names=lpar1
The Memory Affinity Score describes how close processors and memory are, the closer the memory to the memory is, the better is the throughput to the memory. The command above indicates, with a value between 1 and 100, how big the affinity between processors and LPARs is. Our LPAR lpar1 currently has a value of 100, which means the best possible affinity of memory and processors. If the resources were freed when deactivating an LPAR, then the LPAR would lose this Memory Affinity Score. The next time you enable the LPAR, it then depends on the memory and processors available then how good the memory affinity will be then. We release the resources once:
linux $ lpar -d rmprocs lpar1 1 linux $
HMC command line:
hmc01: chhwres -m ms09 -r proc -o r -p lpar1 --procs 1
No more score will be given, since the LPAR has no longer allocated any resources:
linux $ lpar lsmemopt lpar1 LPAR_SCORE LPAR_NAME CURR PREDICTED lpar1 none none linux $
HMC command line:
hmc01: lsmemopt -m ms09 -r lpar -o currscore –filter lpar_names=lpar1
Now we allocate resources again and look at the effect this has on memory affinity:
linux $ lpar applyprof lpar1 standard linux $
HMC command line:
hmc01: chsyscfg -r lpar -m ms09 -o apply -p lpar1 -n standard
We again determine the Memory Affinity Score:
linux $ lpar lsmemopt lpar1 LPAR_SCORE LPAR_NAME CURR PREDICTED lpar1 53 0 linux $
HMC command line:
hmc01: lsmemopt -m ms09 -r lpar -o currscore –filter lpar_names=lpar1
The score is now only 53, the performance of the LPAR has become worse. Whether and how much this is noticeable, depends ultimately on the applications on the LPAR.
The fact that the resources are not released when deactivating an LPAR, thus guarantees the next time you activate (with the current configuration) the memory affinity remains the same and thus the performance should be the same.
If you release the resources of an LPAR (manually or automatically), then you have to realize that this has an effect on the LPAR if it is later activated again, because then the resources are reassigned and a worse (but possibly also a better) Memory Affinity Score can result.
Conversely, before activating a new LPAR you can also make sure that there is a good chance for a high memory affinity score for the new LPAR by releasing resources of inactive LPARs.
(Note: resource distribution can be changed and improved at runtime using the Dynamic Platform Optimizer DPO. DPO is supported as of POWER8.)