Re: [PATCH v2 2/2] powerpc/pseries: new lparcfg key/value pair: partition_affinity_score

Michael Ellerman [off-list ref] writes:

Tyrel Datwyler [off-list ref] writes:

quoted

On 7/27/20 11:46 AM, Scott Cheloha wrote:

quoted

The H_GetPerformanceCounterInfo (GPCI) PHYP hypercall has a subcall,
Affinity_Domain_Info_By_Partition, which returns, among other things,
a "partition affinity score" for a given LPAR.  This score, a value on
[0-100], represents the processor-memory affinity for the LPAR in
question.  A score of 0 indicates the worst possible affinity while a
score of 100 indicates perfect affinity.  The score can be used to
reason about performance.

This patch adds the score for the local LPAR to the lparcfg procfile
under a new 'partition_affinity_score' key.

Signed-off-by: Scott Cheloha <redacted>

I was hoping Michael would chime in the first time around on this patch series
about adding another key/value pair to lparcfg.

That guy is so unreliable.

I don't love adding new stuff in lparcfg, but given the file already
exists and there's no prospect of removing it, it's probably not worth
the effort to put the new field anywhere else.

My other query with this was how on earth anyone is meant to interpret
the metric. ie. if my metric is 50, what does that mean? If it's 90
should I worry?

Here's some more background.

This interface is just passing up what the platform provides, and it's
identical to the partition affinity score described in the documentation
for the management console's lsmemopt command:

https://www.ibm.com/support/knowledgecenter/POWER9/p9edm/lsmemopt.html

The score is 0-100, higher values are better. To illustrate: I believe a
partition's score will be 100 (or very close to it) if all of its CPUs
and memory reside within one node. It will be lower than that when a
partition has some memory without local CPUs, and lower still when there
is no CPU-memory affinity within the partition. Beyond that I don't have
more specific information and the algorithm and scale are set by the
platform.

The intent is for this to be a metric to gather during problem
determination e.g. via sosreport or similar, but as far as Linux is
concerned this should be treated as an opaque value.