From: "Michal Suchánek" <msuchanek@suse.de>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: "Nysal Jan K.A." <nysal@linux.ibm.com>,
Thomas Gleixner <tglx@linutronix.de>,
Tyrel Datwyler <tyreld@linux.ibm.com>,
Nicholas Piggin <npiggin@gmail.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
Peter Zijlstra <peterz@infradead.org>,
Laurent Dufour <ldufour@linux.ibm.com>,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2] Skip offline cores when enabling SMT on PowerPC
Date: Thu, 13 Jun 2024 14:07:04 +0200 [thread overview]
Message-ID: <20240613120704.GI19642@kitsune.suse.cz> (raw)
In-Reply-To: <875xudoz4d.fsf@mail.lhotse>
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
next prev parent reply other threads:[~2024-06-13 12:07 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-12 18:50 [PATCH 0/2] Skip offline cores when enabling SMT on PowerPC Nysal Jan K.A.
2024-06-12 18:50 ` [PATCH 1/2] cpu/SMT: Enable SMT only if a core is online Nysal Jan K.A.
2024-06-12 18:50 ` [PATCH 2/2] powerpc/topology: Check " Nysal Jan K.A.
2024-06-24 19:06 ` Shrikanth Hegde
2024-06-25 6:13 ` Nysal Jan K.A.
2024-06-13 11:34 ` [PATCH 0/2] Skip offline cores when enabling SMT on PowerPC Michael Ellerman
2024-06-13 12:07 ` Michal Suchánek [this message]
2024-06-14 3:52 ` Nysal Jan K.A.
2024-06-23 20:14 ` Thomas Gleixner
2024-06-24 19:11 ` Shrikanth Hegde
2024-06-24 21:24 ` Thomas Gleixner
2024-07-01 4:54 ` Shrikanth Hegde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240613120704.GI19642@kitsune.suse.cz \
--to=msuchanek@suse.de \
--cc=christophe.leroy@csgroup.eu \
--cc=ldufour@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=naveen.n.rao@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=nysal@linux.ibm.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=tyreld@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox