* Re: [PATCH 0/2] Skip offline cores when enabling SMT on PowerPC
@ 2024-06-13 11:34 ` Michael Ellerman
0 siblings, 0 replies; 24+ messages in thread
From: Michael Ellerman @ 2024-06-13 11:34 UTC (permalink / raw)
To: Nysal Jan K.A., Thomas Gleixner
Cc: Tyrel Datwyler, Michal Suchanek, Nysal Jan K.A, Nicholas Piggin,
Christophe Leroy, Naveen N. Rao, Peter Zijlstra, Laurent Dufour,
linuxppc-dev, linux-kernel
"Nysal Jan K.A." <nysal@linux.ibm.com> writes:
> From: "Nysal Jan K.A" <nysal@linux.ibm.com>
>
> After the addition of HOTPLUG_SMT support for PowerPC [1] there was a
> regression reported [2] when enabling SMT.
This implies it was a kernel regression. But it can't be a kernel
regression because previously there was no support at all for the sysfs
interface on powerpc.
IIUIC the regression was in the ppc64_cpu userspace tool, which switched
to using the new kernel interface without taking into account the way it
behaves.
Or are you saying the kernel behaviour changed on x86 after the powerpc
HOTPLUG_SMT was added?
> On a system with at least
> one offline core, when enabling SMT, the expectation is that no CPUs
> of offline cores are made online.
>
> On a POWER9 system with 4 cores in SMT4 mode:
> $ ppc64_cpu --info
> Core 0: 0* 1* 2* 3*
> Core 1: 4* 5* 6* 7*
> Core 2: 8* 9* 10* 11*
> Core 3: 12* 13* 14* 15*
>
> Turn only one core on:
> $ ppc64_cpu --cores-on=1
> $ ppc64_cpu --info
> Core 0: 0* 1* 2* 3*
> Core 1: 4 5 6 7
> Core 2: 8 9 10 11
> Core 3: 12 13 14 15
>
> Change the SMT level to 2:
> $ ppc64_cpu --smt=2
> $ ppc64_cpu --info
> Core 0: 0* 1* 2 3
> Core 1: 4 5 6 7
> Core 2: 8 9 10 11
> Core 3: 12 13 14 15
>
> As expected we see only two CPUs of core 0 are online
>
> Change the SMT level to 4:
> $ ppc64_cpu --smt=4
> $ ppc64_cpu --info
> Core 0: 0* 1* 2* 3*
> Core 1: 4* 5* 6* 7*
> Core 2: 8* 9* 10* 11*
> Core 3: 12* 13* 14* 15*
>
> The CPUs of offline cores are made online. If a core is offline then
> enabling SMT should not online CPUs of this core.
That's the way the ppc64_cpu tool behaves, but it's not necessarily what
other arches want.
> An arch specific
> function topology_is_core_online() is proposed to address this.
> Another approach is to check the topology_sibling_cpumask() for any
> online siblings. This avoids the need for an arch specific function
> but is less efficient and more importantly this introduces a change
> in existing behaviour on other architectures.
It's only x86 and powerpc right?
Having different behaviour on the only two arches that support the
interface does not seem like a good result.
> What is the expected behaviour on x86 when enabling SMT and certain cores
> are offline?
AFAIK no one really touches SMT on x86 other than to turn it off for
security reasons.
cheers
> [1] https://lore.kernel.org/lkml/20230705145143.40545-1-ldufour@linux.ibm.com/
> [2] https://groups.google.com/g/powerpc-utils-devel/c/wrwVzAAnRlI/m/5KJSoqP4BAAJ
>
> Nysal Jan K.A (2):
> cpu/SMT: Enable SMT only if a core is online
> powerpc/topology: Check if a core is online
>
> arch/powerpc/include/asm/topology.h | 13 +++++++++++++
> kernel/cpu.c | 12 +++++++++++-
> 2 files changed, 24 insertions(+), 1 deletion(-)
>
>
> base-commit: c760b3725e52403dc1b28644fb09c47a83cacea6
> --
> 2.35.3
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/2] Skip offline cores when enabling SMT on PowerPC
2024-06-13 11:34 ` Michael Ellerman
@ 2024-06-13 12:07 ` Michal Suchánek
-1 siblings, 0 replies; 24+ messages in thread
From: Michal Suchánek @ 2024-06-13 12:07 UTC (permalink / raw)
To: Michael Ellerman
Cc: Tyrel Datwyler, Peter Zijlstra, Nicholas Piggin, linux-kernel,
Christophe Leroy, Nysal Jan K.A., Naveen N. Rao, Thomas Gleixner,
Laurent Dufour, linuxppc-dev
On Thu, Jun 13, 2024 at 09:34:10PM +1000, Michael Ellerman wrote:
> "Nysal Jan K.A." <nysal@linux.ibm.com> writes:
> > From: "Nysal Jan K.A" <nysal@linux.ibm.com>
> >
> > After the addition of HOTPLUG_SMT support for PowerPC [1] there was a
> > regression reported [2] when enabling SMT.
>
> This implies it was a kernel regression. But it can't be a kernel
> regression because previously there was no support at all for the sysfs
> interface on powerpc.
>
> IIUIC the regression was in the ppc64_cpu userspace tool, which switched
> to using the new kernel interface without taking into account the way it
> behaves.
The reported regression is in the ppc64_cpu tool behavior.
> Or are you saying the kernel behaviour changed on x86 after the powerpc
> HOTPLUG_SMT was added?
>
> > On a system with at least
> > one offline core, when enabling SMT, the expectation is that no CPUs
> > of offline cores are made online.
> >
> > On a POWER9 system with 4 cores in SMT4 mode:
> > $ ppc64_cpu --info
> > Core 0: 0* 1* 2* 3*
> > Core 1: 4* 5* 6* 7*
> > Core 2: 8* 9* 10* 11*
> > Core 3: 12* 13* 14* 15*
> >
> > Turn only one core on:
> > $ ppc64_cpu --cores-on=1
> > $ ppc64_cpu --info
> > Core 0: 0* 1* 2* 3*
> > Core 1: 4 5 6 7
> > Core 2: 8 9 10 11
> > Core 3: 12 13 14 15
> >
> > Change the SMT level to 2:
> > $ ppc64_cpu --smt=2
> > $ ppc64_cpu --info
> > Core 0: 0* 1* 2 3
> > Core 1: 4 5 6 7
> > Core 2: 8 9 10 11
> > Core 3: 12 13 14 15
> >
> > As expected we see only two CPUs of core 0 are online
> >
> > Change the SMT level to 4:
> > $ ppc64_cpu --smt=4
> > $ ppc64_cpu --info
> > Core 0: 0* 1* 2* 3*
> > Core 1: 4* 5* 6* 7*
> > Core 2: 8* 9* 10* 11*
> > Core 3: 12* 13* 14* 15*
> >
> > The CPUs of offline cores are made online. If a core is offline then
> > enabling SMT should not online CPUs of this core.
>
> That's the way the ppc64_cpu tool behaves, but it's not necessarily what
> other arches want.
>
> > An arch specific
> > function topology_is_core_online() is proposed to address this.
> > Another approach is to check the topology_sibling_cpumask() for any
> > online siblings. This avoids the need for an arch specific function
> > but is less efficient and more importantly this introduces a change
> > in existing behaviour on other architectures.
>
> It's only x86 and powerpc right?
>
> Having different behaviour on the only two arches that support the
> interface does not seem like a good result.
That's unfortunate. At the same time changing the x86 behavior would
potentially lead to similar reports from people relying on the old
behavior.
> > What is the expected behaviour on x86 when enabling SMT and certain cores
> > are offline?
>
> AFAIK no one really touches SMT on x86 other than to turn it off for
> security reasons.
In particular I am not aware of x86 suporting those middle partially
enabled states. I don't have a x86 4+ way SMT cpu at hand to test, either.
The more likely excuse is that there is little use case for enabling
previously disabled CPUs (whole cores/thread groups) by changing the SMT
state, even if the SMT code happened to do it in the past.
That is, more technically, that the value of 'off' is 1 - 1 thread of
each core is enabled, and another value representing 'core disabled'
with no thread of the core running is to be treated specially, and not
changed when setting the system-wide SMT value.
These are separate concerns, and should be addressed by separate
interfaces.
Thanks
Michal
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/2] Skip offline cores when enabling SMT on PowerPC
@ 2024-06-13 12:07 ` Michal Suchánek
0 siblings, 0 replies; 24+ messages in thread
From: Michal Suchánek @ 2024-06-13 12:07 UTC (permalink / raw)
To: Michael Ellerman
Cc: Nysal Jan K.A., Thomas Gleixner, Tyrel Datwyler, Nicholas Piggin,
Christophe Leroy, Naveen N. Rao, Peter Zijlstra, Laurent Dufour,
linuxppc-dev, linux-kernel
On Thu, Jun 13, 2024 at 09:34:10PM +1000, Michael Ellerman wrote:
> "Nysal Jan K.A." <nysal@linux.ibm.com> writes:
> > From: "Nysal Jan K.A" <nysal@linux.ibm.com>
> >
> > After the addition of HOTPLUG_SMT support for PowerPC [1] there was a
> > regression reported [2] when enabling SMT.
>
> This implies it was a kernel regression. But it can't be a kernel
> regression because previously there was no support at all for the sysfs
> interface on powerpc.
>
> IIUIC the regression was in the ppc64_cpu userspace tool, which switched
> to using the new kernel interface without taking into account the way it
> behaves.
The reported regression is in the ppc64_cpu tool behavior.
> Or are you saying the kernel behaviour changed on x86 after the powerpc
> HOTPLUG_SMT was added?
>
> > On a system with at least
> > one offline core, when enabling SMT, the expectation is that no CPUs
> > of offline cores are made online.
> >
> > On a POWER9 system with 4 cores in SMT4 mode:
> > $ ppc64_cpu --info
> > Core 0: 0* 1* 2* 3*
> > Core 1: 4* 5* 6* 7*
> > Core 2: 8* 9* 10* 11*
> > Core 3: 12* 13* 14* 15*
> >
> > Turn only one core on:
> > $ ppc64_cpu --cores-on=1
> > $ ppc64_cpu --info
> > Core 0: 0* 1* 2* 3*
> > Core 1: 4 5 6 7
> > Core 2: 8 9 10 11
> > Core 3: 12 13 14 15
> >
> > Change the SMT level to 2:
> > $ ppc64_cpu --smt=2
> > $ ppc64_cpu --info
> > Core 0: 0* 1* 2 3
> > Core 1: 4 5 6 7
> > Core 2: 8 9 10 11
> > Core 3: 12 13 14 15
> >
> > As expected we see only two CPUs of core 0 are online
> >
> > Change the SMT level to 4:
> > $ ppc64_cpu --smt=4
> > $ ppc64_cpu --info
> > Core 0: 0* 1* 2* 3*
> > Core 1: 4* 5* 6* 7*
> > Core 2: 8* 9* 10* 11*
> > Core 3: 12* 13* 14* 15*
> >
> > The CPUs of offline cores are made online. If a core is offline then
> > enabling SMT should not online CPUs of this core.
>
> That's the way the ppc64_cpu tool behaves, but it's not necessarily what
> other arches want.
>
> > An arch specific
> > function topology_is_core_online() is proposed to address this.
> > Another approach is to check the topology_sibling_cpumask() for any
> > online siblings. This avoids the need for an arch specific function
> > but is less efficient and more importantly this introduces a change
> > in existing behaviour on other architectures.
>
> It's only x86 and powerpc right?
>
> Having different behaviour on the only two arches that support the
> interface does not seem like a good result.
That's unfortunate. At the same time changing the x86 behavior would
potentially lead to similar reports from people relying on the old
behavior.
> > What is the expected behaviour on x86 when enabling SMT and certain cores
> > are offline?
>
> AFAIK no one really touches SMT on x86 other than to turn it off for
> security reasons.
In particular I am not aware of x86 suporting those middle partially
enabled states. I don't have a x86 4+ way SMT cpu at hand to test, either.
The more likely excuse is that there is little use case for enabling
previously disabled CPUs (whole cores/thread groups) by changing the SMT
state, even if the SMT code happened to do it in the past.
That is, more technically, that the value of 'off' is 1 - 1 thread of
each core is enabled, and another value representing 'core disabled'
with no thread of the core running is to be treated specially, and not
changed when setting the system-wide SMT value.
These are separate concerns, and should be addressed by separate
interfaces.
Thanks
Michal
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/2] Skip offline cores when enabling SMT on PowerPC
2024-06-13 11:34 ` Michael Ellerman
@ 2024-06-14 3:52 ` Nysal Jan K.A.
-1 siblings, 0 replies; 24+ messages in thread
From: Nysal Jan K.A. @ 2024-06-14 3:52 UTC (permalink / raw)
To: Michael Ellerman
Cc: Tyrel Datwyler, Laurent Dufour, Peter Zijlstra, linux-kernel,
Christophe Leroy, Nicholas Piggin, Naveen N. Rao, Thomas Gleixner,
Michal Suchanek, linuxppc-dev
On Thu, Jun 13, 2024 at 09:34:10PM GMT, Michael Ellerman wrote:
> "Nysal Jan K.A." <nysal@linux.ibm.com> writes:
> > From: "Nysal Jan K.A" <nysal@linux.ibm.com>
> >
> > After the addition of HOTPLUG_SMT support for PowerPC [1] there was a
> > regression reported [2] when enabling SMT.
>
> This implies it was a kernel regression. But it can't be a kernel
> regression because previously there was no support at all for the sysfs
> interface on powerpc.
>
> IIUIC the regression was in the ppc64_cpu userspace tool, which switched
> to using the new kernel interface without taking into account the way it
> behaves.
>
> Or are you saying the kernel behaviour changed on x86 after the powerpc
> HOTPLUG_SMT was added?
>
The regression is in ppc64_cpu. If we need the older behaviour we will need this
or an equivalent change in the kernel though. Fixing it in userspace in an
efficient way might be difficult.
> > On a system with at least
> > one offline core, when enabling SMT, the expectation is that no CPUs
> > of offline cores are made online.
> >
> > On a POWER9 system with 4 cores in SMT4 mode:
> > $ ppc64_cpu --info
> > Core 0: 0* 1* 2* 3*
> > Core 1: 4* 5* 6* 7*
> > Core 2: 8* 9* 10* 11*
> > Core 3: 12* 13* 14* 15*
> >
> > Turn only one core on:
> > $ ppc64_cpu --cores-on=1
> > $ ppc64_cpu --info
> > Core 0: 0* 1* 2* 3*
> > Core 1: 4 5 6 7
> > Core 2: 8 9 10 11
> > Core 3: 12 13 14 15
> >
> > Change the SMT level to 2:
> > $ ppc64_cpu --smt=2
> > $ ppc64_cpu --info
> > Core 0: 0* 1* 2 3
> > Core 1: 4 5 6 7
> > Core 2: 8 9 10 11
> > Core 3: 12 13 14 15
> >
> > As expected we see only two CPUs of core 0 are online
> >
> > Change the SMT level to 4:
> > $ ppc64_cpu --smt=4
> > $ ppc64_cpu --info
> > Core 0: 0* 1* 2* 3*
> > Core 1: 4* 5* 6* 7*
> > Core 2: 8* 9* 10* 11*
> > Core 3: 12* 13* 14* 15*
> >
> > The CPUs of offline cores are made online. If a core is offline then
> > enabling SMT should not online CPUs of this core.
>
> That's the way the ppc64_cpu tool behaves, but it's not necessarily what
> other arches want.
>
True, but from a user perspective it seems logical though. I think one can make
a case for either behaviour.
> > An arch specific
> > function topology_is_core_online() is proposed to address this.
> > Another approach is to check the topology_sibling_cpumask() for any
> > online siblings. This avoids the need for an arch specific function
> > but is less efficient and more importantly this introduces a change
> > in existing behaviour on other architectures.
>
> It's only x86 and powerpc right?
>
> Having different behaviour on the only two arches that support the
> interface does not seem like a good result.
>
Agree, I was originally thinking of sending out a patch changing this for both
architectures, but was unsure if there might be users who now depend on this
behaviour on x86.
> > What is the expected behaviour on x86 when enabling SMT and certain cores
> > are offline?
>
> AFAIK no one really touches SMT on x86 other than to turn it off for
> security reasons.
>
> cheers
>
Thanks for your comments. It will be good to hear if changing this behaviour
for both x86 and PowerPC might be an acceptable path forward.
Regards
--Nysal
> > [1] https://lore.kernel.org/lkml/20230705145143.40545-1-ldufour@linux.ibm.com/
> > [2] https://groups.google.com/g/powerpc-utils-devel/c/wrwVzAAnRlI/m/5KJSoqP4BAAJ
> >
> > Nysal Jan K.A (2):
> > cpu/SMT: Enable SMT only if a core is online
> > powerpc/topology: Check if a core is online
> >
> > arch/powerpc/include/asm/topology.h | 13 +++++++++++++
> > kernel/cpu.c | 12 +++++++++++-
> > 2 files changed, 24 insertions(+), 1 deletion(-)
> >
> >
> > base-commit: c760b3725e52403dc1b28644fb09c47a83cacea6
> > --
> > 2.35.3
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/2] Skip offline cores when enabling SMT on PowerPC
@ 2024-06-14 3:52 ` Nysal Jan K.A.
0 siblings, 0 replies; 24+ messages in thread
From: Nysal Jan K.A. @ 2024-06-14 3:52 UTC (permalink / raw)
To: Michael Ellerman
Cc: Thomas Gleixner, Tyrel Datwyler, Michal Suchanek, Nicholas Piggin,
Christophe Leroy, Naveen N. Rao, Peter Zijlstra, Laurent Dufour,
linuxppc-dev, linux-kernel
On Thu, Jun 13, 2024 at 09:34:10PM GMT, Michael Ellerman wrote:
> "Nysal Jan K.A." <nysal@linux.ibm.com> writes:
> > From: "Nysal Jan K.A" <nysal@linux.ibm.com>
> >
> > After the addition of HOTPLUG_SMT support for PowerPC [1] there was a
> > regression reported [2] when enabling SMT.
>
> This implies it was a kernel regression. But it can't be a kernel
> regression because previously there was no support at all for the sysfs
> interface on powerpc.
>
> IIUIC the regression was in the ppc64_cpu userspace tool, which switched
> to using the new kernel interface without taking into account the way it
> behaves.
>
> Or are you saying the kernel behaviour changed on x86 after the powerpc
> HOTPLUG_SMT was added?
>
The regression is in ppc64_cpu. If we need the older behaviour we will need this
or an equivalent change in the kernel though. Fixing it in userspace in an
efficient way might be difficult.
> > On a system with at least
> > one offline core, when enabling SMT, the expectation is that no CPUs
> > of offline cores are made online.
> >
> > On a POWER9 system with 4 cores in SMT4 mode:
> > $ ppc64_cpu --info
> > Core 0: 0* 1* 2* 3*
> > Core 1: 4* 5* 6* 7*
> > Core 2: 8* 9* 10* 11*
> > Core 3: 12* 13* 14* 15*
> >
> > Turn only one core on:
> > $ ppc64_cpu --cores-on=1
> > $ ppc64_cpu --info
> > Core 0: 0* 1* 2* 3*
> > Core 1: 4 5 6 7
> > Core 2: 8 9 10 11
> > Core 3: 12 13 14 15
> >
> > Change the SMT level to 2:
> > $ ppc64_cpu --smt=2
> > $ ppc64_cpu --info
> > Core 0: 0* 1* 2 3
> > Core 1: 4 5 6 7
> > Core 2: 8 9 10 11
> > Core 3: 12 13 14 15
> >
> > As expected we see only two CPUs of core 0 are online
> >
> > Change the SMT level to 4:
> > $ ppc64_cpu --smt=4
> > $ ppc64_cpu --info
> > Core 0: 0* 1* 2* 3*
> > Core 1: 4* 5* 6* 7*
> > Core 2: 8* 9* 10* 11*
> > Core 3: 12* 13* 14* 15*
> >
> > The CPUs of offline cores are made online. If a core is offline then
> > enabling SMT should not online CPUs of this core.
>
> That's the way the ppc64_cpu tool behaves, but it's not necessarily what
> other arches want.
>
True, but from a user perspective it seems logical though. I think one can make
a case for either behaviour.
> > An arch specific
> > function topology_is_core_online() is proposed to address this.
> > Another approach is to check the topology_sibling_cpumask() for any
> > online siblings. This avoids the need for an arch specific function
> > but is less efficient and more importantly this introduces a change
> > in existing behaviour on other architectures.
>
> It's only x86 and powerpc right?
>
> Having different behaviour on the only two arches that support the
> interface does not seem like a good result.
>
Agree, I was originally thinking of sending out a patch changing this for both
architectures, but was unsure if there might be users who now depend on this
behaviour on x86.
> > What is the expected behaviour on x86 when enabling SMT and certain cores
> > are offline?
>
> AFAIK no one really touches SMT on x86 other than to turn it off for
> security reasons.
>
> cheers
>
Thanks for your comments. It will be good to hear if changing this behaviour
for both x86 and PowerPC might be an acceptable path forward.
Regards
--Nysal
> > [1] https://lore.kernel.org/lkml/20230705145143.40545-1-ldufour@linux.ibm.com/
> > [2] https://groups.google.com/g/powerpc-utils-devel/c/wrwVzAAnRlI/m/5KJSoqP4BAAJ
> >
> > Nysal Jan K.A (2):
> > cpu/SMT: Enable SMT only if a core is online
> > powerpc/topology: Check if a core is online
> >
> > arch/powerpc/include/asm/topology.h | 13 +++++++++++++
> > kernel/cpu.c | 12 +++++++++++-
> > 2 files changed, 24 insertions(+), 1 deletion(-)
> >
> >
> > base-commit: c760b3725e52403dc1b28644fb09c47a83cacea6
> > --
> > 2.35.3
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/2] Skip offline cores when enabling SMT on PowerPC
2024-06-13 11:34 ` Michael Ellerman
@ 2024-06-23 20:14 ` Thomas Gleixner
-1 siblings, 0 replies; 24+ messages in thread
From: Thomas Gleixner @ 2024-06-23 20:14 UTC (permalink / raw)
To: Michael Ellerman, Nysal Jan K.A.
Cc: Tyrel Datwyler, Laurent Dufour, Peter Zijlstra, Nicholas Piggin,
linux-kernel, Christophe Leroy, Nysal Jan K.A, Naveen N. Rao,
Michal Suchanek, linuxppc-dev
Michael!
On Thu, Jun 13 2024 at 21:34, Michael Ellerman wrote:
> IIUIC the regression was in the ppc64_cpu userspace tool, which switched
> to using the new kernel interface without taking into account the way it
> behaves.
>
> Or are you saying the kernel behaviour changed on x86 after the powerpc
> HOTPLUG_SMT was added?
No. The mechanism was always this way. Only offline nodes have been
skipped. x86 never checked for the core being online.
> It's only x86 and powerpc right?
>
> Having different behaviour on the only two arches that support the
> interface does not seem like a good result.
>
>> What is the expected behaviour on x86 when enabling SMT and certain cores
>> are offline?
>
> AFAIK no one really touches SMT on x86 other than to turn it off for
> security reasons.
Right. So changing it not to online a thread when the full core is
offline should not really break stuff.
OTH, the mechanism to figure that out on x86 is definitely different and
more complicated than on power because the sibling threads are not
having consecutive CPU numbers.
So I'm not sure whether it's worth to make this consistent and I
definitely can live with the proposed patches.
Thanks,
tglx
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 0/2] Skip offline cores when enabling SMT on PowerPC
@ 2024-06-23 20:14 ` Thomas Gleixner
0 siblings, 0 replies; 24+ messages in thread
From: Thomas Gleixner @ 2024-06-23 20:14 UTC (permalink / raw)
To: Michael Ellerman, Nysal Jan K.A.
Cc: Tyrel Datwyler, Michal Suchanek, Nysal Jan K.A, Nicholas Piggin,
Christophe Leroy, Naveen N. Rao, Peter Zijlstra, Laurent Dufour,
linuxppc-dev, linux-kernel
Michael!
On Thu, Jun 13 2024 at 21:34, Michael Ellerman wrote:
> IIUIC the regression was in the ppc64_cpu userspace tool, which switched
> to using the new kernel interface without taking into account the way it
> behaves.
>
> Or are you saying the kernel behaviour changed on x86 after the powerpc
> HOTPLUG_SMT was added?
No. The mechanism was always this way. Only offline nodes have been
skipped. x86 never checked for the core being online.
> It's only x86 and powerpc right?
>
> Having different behaviour on the only two arches that support the
> interface does not seem like a good result.
>
>> What is the expected behaviour on x86 when enabling SMT and certain cores
>> are offline?
>
> AFAIK no one really touches SMT on x86 other than to turn it off for
> security reasons.
Right. So changing it not to online a thread when the full core is
offline should not really break stuff.
OTH, the mechanism to figure that out on x86 is definitely different and
more complicated than on power because the sibling threads are not
having consecutive CPU numbers.
So I'm not sure whether it's worth to make this consistent and I
definitely can live with the proposed patches.
Thanks,
tglx
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 0/2] Skip offline cores when enabling SMT on PowerPC
2024-06-23 20:14 ` Thomas Gleixner
@ 2024-06-24 19:11 ` Shrikanth Hegde
-1 siblings, 0 replies; 24+ messages in thread
From: Shrikanth Hegde @ 2024-06-24 19:11 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Tyrel Datwyler, Laurent Dufour, Peter Zijlstra, linux-kernel,
Christophe Leroy, Nicholas Piggin, Naveen N. Rao, Michal Suchanek,
linuxppc-dev, Nysal Jan K.A.
On 6/24/24 1:44 AM, Thomas Gleixner wrote:
> Michael!
>
> On Thu, Jun 13 2024 at 21:34, Michael Ellerman wrote:
>> IIUIC the regression was in the ppc64_cpu userspace tool, which switched
>> to using the new kernel interface without taking into account the way it
>> behaves.
>>
>> Or are you saying the kernel behaviour changed on x86 after the powerpc
>> HOTPLUG_SMT was added?
>
> No. The mechanism was always this way. Only offline nodes have been
> skipped. x86 never checked for the core being online.
>
>> It's only x86 and powerpc right?
>>
>> Having different behaviour on the only two arches that support the
>> interface does not seem like a good result.
>>
>>> What is the expected behaviour on x86 when enabling SMT and certain cores
>>> are offline?
>>
>> AFAIK no one really touches SMT on x86 other than to turn it off for
>> security reasons.
>
> Right. So changing it not to online a thread when the full core is
> offline should not really break stuff.
>
> OTH, the mechanism to figure that out on x86 is definitely different and
> more complicated than on power because the sibling threads are not
> having consecutive CPU numbers.
wouldn't topology_sibling_cpumask have this info?
If the mask is empty does it mean the core is offline?
>
> So I'm not sure whether it's worth to make this consistent and I
> definitely can live with the proposed patches.
>
> Thanks,
>
> tglx
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/2] Skip offline cores when enabling SMT on PowerPC
@ 2024-06-24 19:11 ` Shrikanth Hegde
0 siblings, 0 replies; 24+ messages in thread
From: Shrikanth Hegde @ 2024-06-24 19:11 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Tyrel Datwyler, Michal Suchanek, Nicholas Piggin,
Christophe Leroy, Naveen N. Rao, Peter Zijlstra, Laurent Dufour,
linuxppc-dev, linux-kernel, Michael Ellerman, Nysal Jan K.A.
On 6/24/24 1:44 AM, Thomas Gleixner wrote:
> Michael!
>
> On Thu, Jun 13 2024 at 21:34, Michael Ellerman wrote:
>> IIUIC the regression was in the ppc64_cpu userspace tool, which switched
>> to using the new kernel interface without taking into account the way it
>> behaves.
>>
>> Or are you saying the kernel behaviour changed on x86 after the powerpc
>> HOTPLUG_SMT was added?
>
> No. The mechanism was always this way. Only offline nodes have been
> skipped. x86 never checked for the core being online.
>
>> It's only x86 and powerpc right?
>>
>> Having different behaviour on the only two arches that support the
>> interface does not seem like a good result.
>>
>>> What is the expected behaviour on x86 when enabling SMT and certain cores
>>> are offline?
>>
>> AFAIK no one really touches SMT on x86 other than to turn it off for
>> security reasons.
>
> Right. So changing it not to online a thread when the full core is
> offline should not really break stuff.
>
> OTH, the mechanism to figure that out on x86 is definitely different and
> more complicated than on power because the sibling threads are not
> having consecutive CPU numbers.
wouldn't topology_sibling_cpumask have this info?
If the mask is empty does it mean the core is offline?
>
> So I'm not sure whether it's worth to make this consistent and I
> definitely can live with the proposed patches.
>
> Thanks,
>
> tglx
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/2] Skip offline cores when enabling SMT on PowerPC
2024-06-24 19:11 ` Shrikanth Hegde
@ 2024-06-24 21:24 ` Thomas Gleixner
-1 siblings, 0 replies; 24+ messages in thread
From: Thomas Gleixner @ 2024-06-24 21:24 UTC (permalink / raw)
To: Shrikanth Hegde
Cc: Tyrel Datwyler, Laurent Dufour, Peter Zijlstra, linux-kernel,
Christophe Leroy, Nicholas Piggin, Naveen N. Rao, Michal Suchanek,
linuxppc-dev, Nysal Jan K.A.
On Tue, Jun 25 2024 at 00:41, Shrikanth Hegde wrote:
> On 6/24/24 1:44 AM, Thomas Gleixner wrote:
>> Right. So changing it not to online a thread when the full core is
>> offline should not really break stuff.
>>
>> OTH, the mechanism to figure that out on x86 is definitely different and
>> more complicated than on power because the sibling threads are not
>> having consecutive CPU numbers.
>
> wouldn't topology_sibling_cpumask have this info?
> If the mask is empty does it mean the core is offline?
The mask is not yet available for the to be brought up CPU. That's
established when the CPU boots. It might work because all threads are
brought up during early boot for !~*&^!@% reasons, but then it won't
work under all circumstances, e.g. 'maxcpus=$N'.
We could fix that now with the new topology enumeration code, but that's
a larger scale project.
Thanks,
tglx
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 0/2] Skip offline cores when enabling SMT on PowerPC
@ 2024-06-24 21:24 ` Thomas Gleixner
0 siblings, 0 replies; 24+ messages in thread
From: Thomas Gleixner @ 2024-06-24 21:24 UTC (permalink / raw)
To: Shrikanth Hegde
Cc: Tyrel Datwyler, Michal Suchanek, Nicholas Piggin,
Christophe Leroy, Naveen N. Rao, Peter Zijlstra, Laurent Dufour,
linuxppc-dev, linux-kernel, Michael Ellerman, Nysal Jan K.A.
On Tue, Jun 25 2024 at 00:41, Shrikanth Hegde wrote:
> On 6/24/24 1:44 AM, Thomas Gleixner wrote:
>> Right. So changing it not to online a thread when the full core is
>> offline should not really break stuff.
>>
>> OTH, the mechanism to figure that out on x86 is definitely different and
>> more complicated than on power because the sibling threads are not
>> having consecutive CPU numbers.
>
> wouldn't topology_sibling_cpumask have this info?
> If the mask is empty does it mean the core is offline?
The mask is not yet available for the to be brought up CPU. That's
established when the CPU boots. It might work because all threads are
brought up during early boot for !~*&^!@% reasons, but then it won't
work under all circumstances, e.g. 'maxcpus=$N'.
We could fix that now with the new topology enumeration code, but that's
a larger scale project.
Thanks,
tglx
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 0/2] Skip offline cores when enabling SMT on PowerPC
2024-06-24 21:24 ` Thomas Gleixner
@ 2024-07-01 4:54 ` Shrikanth Hegde
-1 siblings, 0 replies; 24+ messages in thread
From: Shrikanth Hegde @ 2024-07-01 4:54 UTC (permalink / raw)
To: Thomas Gleixner, Nysal Jan K.A.
Cc: Tyrel Datwyler, Laurent Dufour, Peter Zijlstra, linux-kernel,
Christophe Leroy, Nicholas Piggin, Naveen N. Rao, Michal Suchanek,
linuxppc-dev
On 6/25/24 2:54 AM, Thomas Gleixner wrote:
> On Tue, Jun 25 2024 at 00:41, Shrikanth Hegde wrote:
>> On 6/24/24 1:44 AM, Thomas Gleixner wrote:
>>> Right. So changing it not to online a thread when the full core is
>>> offline should not really break stuff.
>>>
>>> OTH, the mechanism to figure that out on x86 is definitely different and
>>> more complicated than on power because the sibling threads are not
>>> having consecutive CPU numbers.
>>
>> wouldn't topology_sibling_cpumask have this info?
>> If the mask is empty does it mean the core is offline?
>
> The mask is not yet available for the to be brought up CPU. That's
> established when the CPU boots. It might work because all threads are
> brought up during early boot for !~*&^!@% reasons, but then it won't
> work under all circumstances, e.g. 'maxcpus=$N'.
>
> We could fix that now with the new topology enumeration code, but that's
> a larger scale project.
Ok.
Can we please document the behavior on different platforms i.e on x86 and PowerPC?
May be in ABI/testing/sysfs-devices-system-cpu?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/2] Skip offline cores when enabling SMT on PowerPC
@ 2024-07-01 4:54 ` Shrikanth Hegde
0 siblings, 0 replies; 24+ messages in thread
From: Shrikanth Hegde @ 2024-07-01 4:54 UTC (permalink / raw)
To: Thomas Gleixner, Nysal Jan K.A.
Cc: Tyrel Datwyler, Michal Suchanek, Nicholas Piggin,
Christophe Leroy, Naveen N. Rao, Peter Zijlstra, Laurent Dufour,
linuxppc-dev, linux-kernel, Michael Ellerman
On 6/25/24 2:54 AM, Thomas Gleixner wrote:
> On Tue, Jun 25 2024 at 00:41, Shrikanth Hegde wrote:
>> On 6/24/24 1:44 AM, Thomas Gleixner wrote:
>>> Right. So changing it not to online a thread when the full core is
>>> offline should not really break stuff.
>>>
>>> OTH, the mechanism to figure that out on x86 is definitely different and
>>> more complicated than on power because the sibling threads are not
>>> having consecutive CPU numbers.
>>
>> wouldn't topology_sibling_cpumask have this info?
>> If the mask is empty does it mean the core is offline?
>
> The mask is not yet available for the to be brought up CPU. That's
> established when the CPU boots. It might work because all threads are
> brought up during early boot for !~*&^!@% reasons, but then it won't
> work under all circumstances, e.g. 'maxcpus=$N'.
>
> We could fix that now with the new topology enumeration code, but that's
> a larger scale project.
Ok.
Can we please document the behavior on different platforms i.e on x86 and PowerPC?
May be in ABI/testing/sysfs-devices-system-cpu?
^ permalink raw reply [flat|nested] 24+ messages in thread