From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Laurent Dufour <ldufour@linux.ibm.com>
Cc: nathanl@linux.ibm.com, linux-kernel@vger.kernel.org,
npiggin@gmail.com, msuchanek@suse.de,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 1/2] pseries/smp: export the smt level in the SYS FS.
Date: Tue, 18 Apr 2023 22:55:25 +0530 [thread overview]
Message-ID: <20230418172525.GK1005120@linux.vnet.ibm.com> (raw)
In-Reply-To: <0e668a82-3a3e-798a-8707-1a9b622b23b6@linux.ibm.com>
* Laurent Dufour <ldufour@linux.ibm.com> [2023-04-13 17:38:51]:
> On 13/04/2023 15:37:59, Michael Ellerman wrote:
> > Hi Laurent,
> >
> > Laurent Dufour <ldufour@linux.ibm.com> writes:
> >> There is no SMT level recorded in the kernel neither in user space.
> >> Indeed there is no real constraint about that and mixed SMT levels are
> >> allowed and system is working fine this way.
> >>
> >> However when new CPU are added, the kernel is onlining all the threads
> >> which is leading to mixed SMT levels and confuse end user a bit.
> >>
> >> To prevent this exports a SMT level from the kernel so user space
> >> application like the energy daemon, could read it to adjust their settings.
> >> There is no action unless recording the value when a SMT value is written
> >> into the new sysfs entry. User space applications like ppc64_cpu should
> >> update the sysfs when changing the SMT level to keep the system consistent.
> >>
> >> Suggested-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
> >> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
> >> ---
> >> arch/powerpc/platforms/pseries/pseries.h | 3 ++
> >> arch/powerpc/platforms/pseries/smp.c | 39 ++++++++++++++++++++++++
> >> 2 files changed, 42 insertions(+)
> >
> > There is a generic sysfs interface for smt in /sys/devices/system/cpu/smt
> >
> > I think we should be enabling that on powerpc and then adapting it to
> > our needs, rather than adding a pseries specific file.
>
> Thanks Michael, I was not aware of this sysfs interface.
>
> > Currently the generic code is only aware of SMT on/off, so it would need
> > to be taught about SMT4 and 8 at least.
>
> Do you think we should limit our support to SMT4 and SMT8 only?
smt2 is also a valid already supported configuration and we are evaluating
smt6 mode based on some inputs from ISV teams.
So I believe having a value for all modes would be good.
>
> > There are already hooks in the generic code to check the SMT level when
> > bringing CPUs up, see cpu_smt_allowed(), they may work for the pseries
> > hotplug case too, though maybe we need some additional logic.
> >
> > Wiring up the basic support is pretty straight forward, something like
> > the diff below.
>
--
Thanks and Regards
Srikar Dronamraju
WARNING: multiple messages have this Message-ID (diff)
From: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
To: Laurent Dufour <ldufour@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
npiggin@gmail.com, christophe.leroy@csgroup.eu,
msuchanek@suse.de, nathanl@linux.ibm.com,
linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 1/2] pseries/smp: export the smt level in the SYS FS.
Date: Tue, 18 Apr 2023 22:55:25 +0530 [thread overview]
Message-ID: <20230418172525.GK1005120@linux.vnet.ibm.com> (raw)
In-Reply-To: <0e668a82-3a3e-798a-8707-1a9b622b23b6@linux.ibm.com>
* Laurent Dufour <ldufour@linux.ibm.com> [2023-04-13 17:38:51]:
> On 13/04/2023 15:37:59, Michael Ellerman wrote:
> > Hi Laurent,
> >
> > Laurent Dufour <ldufour@linux.ibm.com> writes:
> >> There is no SMT level recorded in the kernel neither in user space.
> >> Indeed there is no real constraint about that and mixed SMT levels are
> >> allowed and system is working fine this way.
> >>
> >> However when new CPU are added, the kernel is onlining all the threads
> >> which is leading to mixed SMT levels and confuse end user a bit.
> >>
> >> To prevent this exports a SMT level from the kernel so user space
> >> application like the energy daemon, could read it to adjust their settings.
> >> There is no action unless recording the value when a SMT value is written
> >> into the new sysfs entry. User space applications like ppc64_cpu should
> >> update the sysfs when changing the SMT level to keep the system consistent.
> >>
> >> Suggested-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
> >> Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
> >> ---
> >> arch/powerpc/platforms/pseries/pseries.h | 3 ++
> >> arch/powerpc/platforms/pseries/smp.c | 39 ++++++++++++++++++++++++
> >> 2 files changed, 42 insertions(+)
> >
> > There is a generic sysfs interface for smt in /sys/devices/system/cpu/smt
> >
> > I think we should be enabling that on powerpc and then adapting it to
> > our needs, rather than adding a pseries specific file.
>
> Thanks Michael, I was not aware of this sysfs interface.
>
> > Currently the generic code is only aware of SMT on/off, so it would need
> > to be taught about SMT4 and 8 at least.
>
> Do you think we should limit our support to SMT4 and SMT8 only?
smt2 is also a valid already supported configuration and we are evaluating
smt6 mode based on some inputs from ISV teams.
So I believe having a value for all modes would be good.
>
> > There are already hooks in the generic code to check the SMT level when
> > bringing CPUs up, see cpu_smt_allowed(), they may work for the pseries
> > hotplug case too, though maybe we need some additional logic.
> >
> > Wiring up the basic support is pretty straight forward, something like
> > the diff below.
>
--
Thanks and Regards
Srikar Dronamraju
next prev parent reply other threads:[~2023-04-18 17:26 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-31 15:39 [PATCH 0/2] Online new threads according to the current SMT level Laurent Dufour
2023-03-31 15:39 ` Laurent Dufour
2023-03-31 15:39 ` [PATCH 1/2] pseries/smp: export the smt level in the SYS FS Laurent Dufour
2023-03-31 15:39 ` Laurent Dufour
2023-03-31 16:05 ` Michal Suchánek
2023-03-31 16:05 ` Michal Suchánek
2023-04-03 8:20 ` Laurent Dufour
2023-04-03 8:20 ` Laurent Dufour
2023-04-13 13:37 ` Michael Ellerman
2023-04-13 13:37 ` Michael Ellerman
2023-04-13 15:38 ` Laurent Dufour
2023-04-13 15:38 ` Laurent Dufour
2023-04-14 12:11 ` Michael Ellerman
2023-04-14 12:11 ` Michael Ellerman
2023-04-14 14:38 ` Michal Suchánek
2023-04-14 14:38 ` Michal Suchánek
2023-04-18 17:25 ` Srikar Dronamraju [this message]
2023-04-18 17:25 ` Srikar Dronamraju
2023-03-31 15:39 ` [PATCH 2/2] powerpc/pseries/cpuhp: respect current SMT when adding new CPU Laurent Dufour
2023-03-31 15:39 ` Laurent Dufour
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=20230418172525.GK1005120@linux.vnet.ibm.com \
--to=srikar@linux.vnet.ibm.com \
--cc=ldufour@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=msuchanek@suse.de \
--cc=nathanl@linux.ibm.com \
--cc=npiggin@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.