On 30/10/2026 15:53, Shrikanth Hegde wrote:
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?
Yes, it is virtualized.
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?
So you propose s390 to enable CONFIG_PARAVIRT *just because* s390
fits the "paravirtualized system" definition, even if s390 would not
utilize any functionality comes with the config option? (even worse
it comes with deadcode...)
That sounds a bit wrong to me, I would really like to avoid
enabling a config option just because it's name suggests that
it is related to our platform.
Yury already sent the patch series he mentioned. I suppose we should
keep discussing this there.
Thank you!
-Mete
