From: Laurent Dufour <ldufour@linux.ibm.com>
To: mpe@ellerman.id.au, npiggin@gmail.com, christophe.leroy@csgroup.eu
Cc: nathanl@linux.ibm.com, msuchanek@suse.de,
linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Subject: [PATCH 1/2] pseries/smp: export the smt level in the SYS FS.
Date: Fri, 31 Mar 2023 17:39:04 +0200 [thread overview]
Message-ID: <20230331153905.31698-2-ldufour@linux.ibm.com> (raw)
In-Reply-To: <20230331153905.31698-1-ldufour@linux.ibm.com>
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(+)
diff --git a/arch/powerpc/platforms/pseries/pseries.h b/arch/powerpc/platforms/pseries/pseries.h
index f8bce40ebd0c..af0a145af98f 100644
--- a/arch/powerpc/platforms/pseries/pseries.h
+++ b/arch/powerpc/platforms/pseries/pseries.h
@@ -23,7 +23,9 @@ extern int pSeries_machine_check_exception(struct pt_regs *regs);
extern long pseries_machine_check_realmode(struct pt_regs *regs);
void pSeries_machine_check_log_err(void);
+
#ifdef CONFIG_SMP
+extern int pseries_smt;
extern void smp_init_pseries(void);
/* Get state of physical CPU from query_cpu_stopped */
@@ -34,6 +36,7 @@ int smp_query_cpu_stopped(unsigned int pcpu);
#define QCSS_HARDWARE_ERROR -1
#define QCSS_HARDWARE_BUSY -2
#else
+#define pseries_smt 1
static inline void smp_init_pseries(void) { }
#endif
diff --git a/arch/powerpc/platforms/pseries/smp.c b/arch/powerpc/platforms/pseries/smp.c
index c597711ef20a..6c382922f8f3 100644
--- a/arch/powerpc/platforms/pseries/smp.c
+++ b/arch/powerpc/platforms/pseries/smp.c
@@ -21,6 +21,7 @@
#include <linux/device.h>
#include <linux/cpu.h>
#include <linux/pgtable.h>
+#include <linux/sysfs.h>
#include <asm/ptrace.h>
#include <linux/atomic.h>
@@ -45,6 +46,8 @@
#include "pseries.h"
+int pseries_smt;
+
/*
* The Primary thread of each non-boot processor was started from the OF client
* interface by prom_hold_cpus and is spinning on secondary_hold_spinloop.
@@ -280,3 +283,39 @@ void __init smp_init_pseries(void)
pr_debug(" <- smp_init_pSeries()\n");
}
+
+static ssize_t pseries_smt_store(struct class *class,
+ struct class_attribute *attr,
+ const char *buf, size_t count)
+{
+ int smt;
+
+ if (kstrtou32(buf, 0, &smt) || !smt || smt > (u32) threads_per_core) {
+ pr_err("Invalid pseries_smt specified.\n");
+ return -EINVAL;
+ }
+
+ pseries_smt = smt;
+
+ return count;
+}
+
+static ssize_t pseries_smt_show(struct class *class, struct class_attribute *attr,
+ char *buf)
+{
+ return sysfs_emit(buf, "%d\n", pseries_smt);
+}
+
+static CLASS_ATTR_RW(pseries_smt);
+
+static int __init pseries_smt_init(void)
+{
+ int rc;
+
+ pseries_smt = smt_enabled_at_boot;
+ rc = sysfs_create_file(kernel_kobj, &class_attr_pseries_smt.attr);
+ if (rc)
+ pr_err("Can't create pseries_smt sysfs/kernel entry.\n");
+ return rc;
+}
+machine_device_initcall(pseries, pseries_smt_init);
--
2.40.0
next prev parent reply other threads:[~2023-03-31 15:40 UTC|newest]
Thread overview: 10+ 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 [this message]
2023-03-31 16:05 ` [PATCH 1/2] pseries/smp: export the smt level in the SYS FS Michal Suchánek
2023-04-03 8:20 ` Laurent Dufour
2023-04-13 13:37 ` Michael Ellerman
2023-04-13 15:38 ` Laurent Dufour
2023-04-14 12:11 ` Michael Ellerman
2023-04-14 14:38 ` Michal Suchánek
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
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=20230331153905.31698-2-ldufour@linux.ibm.com \
--to=ldufour@linux.ibm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=msuchanek@suse.de \
--cc=nathanl@linux.ibm.com \
--cc=npiggin@gmail.com \
--cc=srikar@linux.vnet.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;
as well as URLs for NNTP newsgroup(s).