Hi Mete, Yury,
On 10/29/26 10:06 PM, Mete Durlu wrote:
On 29/10/2026 17:28, Yury Norov wrote:
On Thu, Oct 29, 2026 at 02:32:08PM +0100, Mete Durlu wrote:
On 28/09/2026 07:37, Shrikanth Hegde wrote:
Provide the preferred CPU infrastructure. Define get/set macros
which could be used to get/set CPU state as preferred.
CONFIG_PREFERRED_CPU will be selected by the driver which handles
steal time values. It is going to set/clear preferred CPU state.
This driver will be called steal_governor and it is introduced in
subsequent patches. It periodically computes the steal ratio and
decides on preferred CPU state.
A CPU is set to preferred when it becomes active. Later it may be
marked as non-preferred depending on steal ratio by the steal_governor.
Always maintain design construct of preferred is subset of active.
i.e. preferred ⊆ active ⊆ online ⊆ present ⊆ possible
With CONFIG_PREFERRED_CPU=n, ensure set_cpu_preferred is a nop and get
method returns the active state in that case.
Signed-off-by: Shrikanth Hegde <[email protected]>
---
include/linux/cpumask.h | 24 ++++++++++++++++++++++++
kernel/Kconfig.preempt | 4 ++++
kernel/cpu.c | 6 ++++++
kernel/sched/core.c | 5 +++++
4 files changed, 39 insertions(+)
[..snip..]
#define cpu_is_offline(cpu) unlikely(!cpu_online(cpu))
diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
index 985aea617cfe..edc067a0c422 100644
--- a/kernel/Kconfig.preempt
+++ b/kernel/Kconfig.preempt
@@ -194,3 +194,7 @@ config SCHED_CLASS_EXT
For more information:
Documentation/scheduler/sched-ext.rst
https://github.com/sched-ext/scx
+
+config PREFERRED_CPU
+ bool
+ depends on SMP && PARAVIRT
FWICT, PREFERRED_CPU mechanism can work perfectly fine without PARAVIRT
selected. It would be annoying to enable it and implement a dummy
paravirt_steal_clock() just for that.
Shrikanth, would it be possible to drop that dependency?
Do you have a non-paravirt case in mind?
s390 LPARs are exactly that. s390 does not select PARAVIRT by default
but enabling PREFERRED_CPU is strongly considered.
s390 may not have PARAVIRT=y, but this use case is still a virtualizated system
no?
i.e you are observing steal time. By definition of steal time, it is a para-
virtualized system. Though you may be deriving the steal time not using the
paravirt_steal_clock.
Or my understanding here is wrong?
I removed the PARAVIRT dependency and gave the whole thing a quick
spin. Builds and functions w/o any issues on s390!
I'm actually about to submit an RFC that drops the PARAVIRT dependency
and provides write access to the preferred mask. But I want to make
sure that we need it, and we've got no reasonable mechanism to put
unneeded CPUs on idle already.
We might run into few corner cases quickly with write allowed.
But yes, this is a simpler mechanism not to run anything on few CPUs
in a dynamic way.
You can mention s390 LPARs as valid case on your RFC if need be.
Thank you!
