From: Shrikanth Hegde <sshegde@linux.ibm.com>
To: maddy@linux.ibm.com, linuxppc-dev@lists.ozlabs.org,
peterz@infradead.org, tim.c.chen@linux.intel.com
Cc: sshegde@linux.ibm.com, christophe.leroy@csgroup.eu,
linux-kernel@vger.kernel.org, ritesh.list@gmail.com,
kprateek.nayak@amd.com, yu.c.chen@intel.com,
vineethr@linux.ibm.com, vincent.guittot@linaro.org,
srikar@linux.ibm.com, npiggin@gmail.com, mpe@ellerman.id.au
Subject: [PATCH 0/4] powerpc/topology: Introduce llc_override debugfs
Date: Mon, 12 Oct 2026 15:50:33 +0530 [thread overview]
Message-ID: <20261012102037.2477378-1-sshegde@linux.ibm.com> (raw)
There is a new feature in scheduler called as Cache Aware Scheduling [1].
It tries to keep related tasks within the same LLC domain while
keeping the system reasonably balanced.
Cache Aware Scheduling assumes that the scheduler LLC domain is large enough
to be a useful placement target. This is true on many systems where an LLC spans
several cores, but not on PowerPC systems where the scheduler-visible LLC is at
the SMT level. In that case, sd_llc_size is effectively the SMT width.
This becomes visible in the capacity check:
return !fits_capacity((mm->sc_stat.nr_running_avg * cpu_smt_num_threads),
scale * per_cpu(sd_llc_size, cpu));
As a result, Cache aware scheduling may be enabled but has no room to operate.
Hence provide a debugfs option to set LLC at specific domain so that
one can try experiment their workload with cache aware scheduling.
This also provides ways to explore it on system with SMT=4 to see if
there are any opportunities to improve or uncover bugs if there is any.
Note it is a debug option and it is recommended to keep it disabled.
There is no performance guarantees across different values.
[1]: https://lore.kernel.org/all/cover.1778703694.git.tim.c.chen@linux.intel.com/
Tim, Chenyu, Peter,
Are there any selftest or patches which is used for
functional validation of cache aware scheduling?
per-LLC occupancy in /proc/{PID}/schedstat may not tell the full
story when there are multiple processes and multiple LLC's.
Atleast for functional verification, we might need one if there is
not one already. The reason being,
- At present, we may need a custom workload. hackbench/schbench are
wakeup intensive and typically bail out even before load balance.
- stress-ng is per process. So doesn't get cache aware scheduling.
- A selftest could spwan specific number of threads till llc size etc
and ensure packing happens till core_count(llc_size) by default.
This could also be used for tunable verfifications.
- Provide an ability to observe how much of the workload was contained
within the LLC due to cache aware scheduling or number of load
balances stopped due to preferred llc.
These are some initial thoughts I had. If it sounds ok, I can try to add
a new selftest/kunit test.
Shrikanth Hegde (4):
powerpc/topology: Introduce llc_override debug knob
powerpc/topology: Add docs for llc_override
powerpc/topology: Update mc/pkg flags based on llc_override
powerpc/topology: Rebuild sched domains on llc_override change
Documentation/arch/powerpc/index.rst | 1 +
Documentation/arch/powerpc/topology.rst | 27 +++++
arch/powerpc/kernel/smp.c | 128 +++++++++++++++++++++++-
3 files changed, 151 insertions(+), 5 deletions(-)
create mode 100644 Documentation/arch/powerpc/topology.rst
--
2.52.0
next reply other threads:[~2026-10-12 10:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-12 10:20 Shrikanth Hegde [this message]
2026-10-12 10:20 ` [PATCH 1/4] powerpc/topology: Introduce llc_override debug knob Shrikanth Hegde
2026-10-12 12:14 ` Srikar Dronamraju
2026-10-12 14:10 ` Shrikanth Hegde
2026-10-12 10:20 ` [PATCH 2/4] powerpc/topology: Add docs for llc_override Shrikanth Hegde
2026-10-12 10:20 ` [PATCH 3/4] powerpc/topology: Update mc/pkg flags based on llc_override Shrikanth Hegde
2026-10-12 10:20 ` [PATCH 4/4] powerpc/topology: Rebuild sched domains on llc_override change Shrikanth Hegde
2026-10-12 12:19 ` [PATCH 0/4] powerpc/topology: Introduce llc_override debugfs Srikar Dronamraju
2026-10-12 14:14 ` Shrikanth Hegde
2026-10-12 21:15 ` Tim Chen
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=20261012102037.2477378-1-sshegde@linux.ibm.com \
--to=sshegde@linux.ibm.com \
--cc=christophe.leroy@csgroup.eu \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=peterz@infradead.org \
--cc=ritesh.list@gmail.com \
--cc=srikar@linux.ibm.com \
--cc=tim.c.chen@linux.intel.com \
--cc=vincent.guittot@linaro.org \
--cc=vineethr@linux.ibm.com \
--cc=yu.c.chen@intel.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
all inboxes | Powered by JetHome®