[PATCH] lparstat: power10: print memory mode correctly

[Shrikanth Hegde]

Starting from power10, active memory sharing(AMS) is not supported.
So from power10 onwards the H_GET_MPP hcall fails and hence
corresponding fields in lparcfg are not populated, such as
entitled_memory_pool_number etc.

Use gcc builtins and print memory model as dedicated for power10
onwards.

Signed-off-by: Shrikanth Hegde <ssh...@linux.ibm.com>
---
src/lparstat.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/lparstat.c b/src/lparstat.c
index fe8b0fc..6018ccf 100644
--- a/src/lparstat.c
+++ b/src/lparstat.c
@@ -789,7 +789,11 @@ void get_memory_mode(struct sysentry *se, char *buf)
struct sysentry *tmp;

tmp = get_sysentry("entitled_memory_pool_number");
- if (atoi(tmp->value) == 65535)
+ /*
+ * from power10 onwards Active Memory Sharing(AMS) is not
+ * supported. Hence always display it as dedicated for those
+ */
+ if (atoi(tmp->value) == 65535 || __builtin_cpu_supports("arch_3_1"))
sprintf(buf, "Dedicated");
else
sprintf(buf, "Shared");
--
2.39.3

[Shrikanth Hegde]

Ping.

Hi Tyrel, Any concerns with this patch? Can we consider this patch?

[Tyrel Datwyler]

On 1/9/25 1:20 AM, Shrikanth Hegde wrote:
> Starting from power10, active memory sharing(AMS) is not supported.
> So from power10 onwards the H_GET_MPP hcall fails and hence
> corresponding fields in lparcfg are not populated, such as
> entitled_memory_pool_number etc.
>
> Use gcc builtins and print memory model as dedicated for power10
> onwards.

Out of the box this breaks our github CI, but that is only because we also build
against x86_64-linux-gnu in our build matrix since it just works and the CI host
runner is x86_64-linux-gnu. I can remove this target from the build matrix as
this passes with all the ppc cross-compiled targets in our CI. However, it
raises the question is this the only/best way to determine Dedicated vs Shared
with Power10 on wards?

-Tyrel

[Shrikanth Hegde]

On 2/26/25 04:49, Tyrel Datwyler wrote:
> On 1/9/25 1:20 AM, Shrikanth Hegde wrote:
>> Starting from power10, active memory sharing(AMS) is not supported.
>> So from power10 onwards the H_GET_MPP hcall fails and hence
>> corresponding fields in lparcfg are not populated, such as
>> entitled_memory_pool_number etc.
>>
>> Use gcc builtins and print memory model as dedicated for power10
>> onwards.
>
> Out of the box this breaks our github CI, but that is only because we also build
> against x86_64-linux-gnu in our build matrix since it just works and the CI host
> runner is x86_64-linux-gnu. I can remove this target from the build matrix as
> this passes with all the ppc cross-compiled targets in our CI. However, it
> raises the question is this the only/best way to determine Dedicated vs Shared
> with Power10 on wards?

yes i guess. Since it is a userspace. A few other options were to parse
lspcu or lshw. Those seemed more parsing and complicated code compared
to this. Advantage is this has wrappers for any arch after power10,
other methods would need a support when the new version comes up.

[Peter Bergner]

On 2/25/25 5:19 PM, Tyrel Datwyler wrote:
> On 1/9/25 1:20 AM, Shrikanth Hegde wrote:
>> Use gcc builtins and print memory model as dedicated for power10
>> onwards.
>
> Out of the box this breaks our github CI, but that is only because we also build
> against x86_64-linux-gnu in our build matrix since it just works and the CI host
> runner is x86_64-linux-gnu. I can remove this target from the build matrix as
> this passes with all the ppc cross-compiled targets in our CI. However, it
> raises the question is this the only/best way to determine Dedicated vs Shared
> with Power10 on wards?

So the __builtin_cpu_supports() built-in exists on both x86 and Power,
but the compiler will emit an error if you pass in a hwcap string it
doesn't know about and "arch_3_1" is unknown on x86, so hence the build
error when building on x86. You could modify the patch so it compiles
fine on both x86 and Power, ala the patch below. This also prevents a
build error if you build lparstat.c with a old GCC on Power before the
__builtin_cpu_supports was added.

Peter


diff --git a/src/common/cpu_info_helpers.h b/src/common/cpu_info_helpers.h
index 77e6ad7..bd77856 100644
--- a/src/common/cpu_info_helpers.h
+++ b/src/common/cpu_info_helpers.h
@@ -47,4 +47,10 @@ extern int __get_one_smt_state(int core, int threads_per_cpu);
extern int __do_smt(bool numeric, int cpus_in_system, int threads_per_cpu,
bool print_smt_state);

+#if defined (__powerpc__) && defined (__BUILTIN_CPU_SUPPORTS__)
+# define BUILTIN_CPU_SUPPORTS(X) __builtin_cpu_supports(X)
+#else
+# define BUILTIN_CPU_SUPPORTS(X) 0
+#endif
+
#endif /* CPU_INFO_H */
diff --git a/src/lparstat.c b/src/lparstat.c
index db22316..ce89d28 100644
--- a/src/lparstat.c
+++ b/src/lparstat.c
@@ -794,7 +794,11 @@ void get_memory_mode(struct sysentry *se, char *buf)

struct sysentry *tmp;

tmp = get_sysentry("entitled_memory_pool_number");
- if (atoi(tmp->value) == 65535)
+ /*
+ * from power10 onwards Active Memory Sharing(AMS) is not
+ * supported. Hence always display it as dedicated for those
+ */

+ if (atoi(tmp->value) == 65535 || BUILTIN_CPU_SUPPORTS("arch_3_1"))

[Tyrel Datwyler]

On 2/28/25 8:58 AM, Peter Bergner wrote:
> On 2/25/25 5:19 PM, Tyrel Datwyler wrote:
>> On 1/9/25 1:20 AM, Shrikanth Hegde wrote:
>>> Use gcc builtins and print memory model as dedicated for power10
>>> onwards.
>>
>> Out of the box this breaks our github CI, but that is only because we also build
>> against x86_64-linux-gnu in our build matrix since it just works and the CI host
>> runner is x86_64-linux-gnu. I can remove this target from the build matrix as
>> this passes with all the ppc cross-compiled targets in our CI. However, it
>> raises the question is this the only/best way to determine Dedicated vs Shared
>> with Power10 on wards?
>
> So the __builtin_cpu_supports() built-in exists on both x86 and Power,
> but the compiler will emit an error if you pass in a hwcap string it
> doesn't know about and "arch_3_1" is unknown on x86, so hence the build
> error when building on x86. You could modify the patch so it compiles
> fine on both x86 and Power, ala the patch below. This also prevents a
> build error if you build lparstat.c with a old GCC on Power before the
> __builtin_cpu_supports was added.

I would be ok with this approach. Based on latest support notes for PowerVM
everything is dedicated memory from Power10 on, and this would be simpler then
parsing lscpu or lshw as Shrikanth mentioned previously.

-Tyrel

[Shrikanth Hegde]

Thanks. Works for me as well. Let me send v2.