From: Shrikanth Hegde <sshegde@linux.ibm.com>
To: Yury Norov <ynorov@nvidia.com>
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org,
peterz@infradead.org, juri.lelli@redhat.com,
vincent.guittot@linaro.org, yury.norov@gmail.com,
kprateek.nayak@amd.com, iii@linux.ibm.com, corbet@lwn.net,
tglx@kernel.org, gregkh@linuxfoundation.org, pbonzini@redhat.com,
seanjc@google.com, vschneid@redhat.com, huschle@linux.ibm.com,
rostedt@goodmis.org, dietmar.eggemann@arm.com,
maddy@linux.ibm.com, srikar@linux.ibm.com, hdanton@sina.com,
chleroy@kernel.org, vineeth@bitbyteword.org, frederic@kernel.org,
arighi@nvidia.com, pauld@redhat.com, christian.loehle@arm.com,
tj@kernel.org, tommaso.cucinotta@gmail.com, maz@kernel.org,
rafael@kernel.org, rdunlap@infradead.org, kernellwp@gmail.com,
linux-doc@vger.kernel.org
Subject: Re: [PATCH v7 02/12] cpumask: Introduce cpu_preferred_mask
Date: Tue, 14 Jul 2026 12:00:51 +0530 [thread overview]
Message-ID: <df198506-9c6e-4e79-bf3b-798668322708@linux.ibm.com> (raw)
In-Reply-To: <alT78Nzt3xa-7G5Y@yury>
Hi Yury,
On 7/13/26 8:23 PM, Yury Norov wrote:
> On Fri, Jul 10, 2026 at 03:26:38AM +0530, Shrikanth Hegde wrote:
>> Provide cpu_preferred_mask infrastructure. Define get/set macros
>> which could be used to get/set CPU state as preferred.
>>
>> PREFERRED_CPU config 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_monitor and it is introduced in
>> subsequent patches. It periodically samples the steal time 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 time values with
>> steal_monitor being enabled.
>>
>> Always maintain design construct of preferred is subset of active.
>> i.e. preferred ⊆ active ⊆ online ⊆ present ⊆ possible
>>
>> With 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 <sshegde@linux.ibm.com>
>> ---
>> v6->v7:
>> - removed CONFIG_PREFERRED_CPU as user option.
>> - Use do { } while (0) for nop
>>
>> include/linux/cpumask.h | 24 ++++++++++++++++++++++++
>> kernel/Kconfig.preempt | 3 +++
>> kernel/cpu.c | 6 ++++++
>> kernel/sched/core.c | 5 +++++
>> 4 files changed, 38 insertions(+)
>>
>> diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
>> index d3cda0544954..34d08a3d80e1 100644
>> --- a/include/linux/cpumask.h
>> +++ b/include/linux/cpumask.h
>> @@ -122,12 +122,20 @@ extern struct cpumask __cpu_enabled_mask;
>> extern struct cpumask __cpu_present_mask;
>> extern struct cpumask __cpu_active_mask;
>> extern struct cpumask __cpu_dying_mask;
>> +
>> +#ifdef CONFIG_PREFERRED_CPU
>> +extern struct cpumask __cpu_preferred_mask;
>> +#else
>> +#define __cpu_preferred_mask __cpu_active_mask
>> +#endif
>> +
>> #define cpu_possible_mask ((const struct cpumask *)&__cpu_possible_mask)
>> #define cpu_online_mask ((const struct cpumask *)&__cpu_online_mask)
>> #define cpu_enabled_mask ((const struct cpumask *)&__cpu_enabled_mask)
>> #define cpu_present_mask ((const struct cpumask *)&__cpu_present_mask)
>> #define cpu_active_mask ((const struct cpumask *)&__cpu_active_mask)
>> #define cpu_dying_mask ((const struct cpumask *)&__cpu_dying_mask)
>> +#define cpu_preferred_mask ((const struct cpumask *)&__cpu_preferred_mask)
>>
>> extern atomic_t __num_online_cpus;
>> extern unsigned int __num_possible_cpus;
>> @@ -1164,6 +1172,12 @@ void init_cpu_possible(const struct cpumask *src);
>> #define set_cpu_active(cpu, active) assign_cpu((cpu), &__cpu_active_mask, (active))
>> #define set_cpu_dying(cpu, dying) assign_cpu((cpu), &__cpu_dying_mask, (dying))
>>
>> +#ifdef CONFIG_PREFERRED_CPU
>> +#define set_cpu_preferred(cpu, preferred) assign_cpu((cpu), &__cpu_preferred_mask, (preferred))
>> +#else
>> +#define set_cpu_preferred(cpu, preferred) do { } while (0)
>> +#endif
>> +
>> void set_cpu_online(unsigned int cpu, bool online);
>> void set_cpu_possible(unsigned int cpu, bool possible);
>>
>> @@ -1258,6 +1272,11 @@ static __always_inline bool cpu_dying(unsigned int cpu)
>> return cpumask_test_cpu(cpu, cpu_dying_mask);
>> }
>>
>> +static __always_inline bool cpu_preferred(unsigned int cpu)
>> +{
>> + return cpumask_test_cpu(cpu, cpu_preferred_mask);
>> +}
>> +
>> #else
>>
>> #define num_online_cpus() 1U
>> @@ -1296,6 +1315,11 @@ static __always_inline bool cpu_dying(unsigned int cpu)
>> return false;
>> }
>>
>> +static __always_inline bool cpu_preferred(unsigned int cpu)
>> +{
>> + return cpu == 0;
>> +}
>> +
>> #endif /* NR_CPUS > 1 */
>>
>> #define cpu_is_offline(cpu) unlikely(!cpu_online(cpu))
>> diff --git a/kernel/Kconfig.preempt b/kernel/Kconfig.preempt
>> index 88c594c6d7fc..ed02e4431230 100644
>> --- a/kernel/Kconfig.preempt
>> +++ b/kernel/Kconfig.preempt
>> @@ -192,3 +192,6 @@ config SCHED_CLASS_EXT
>> For more information:
>> Documentation/scheduler/sched-ext.rst
>> https://github.com/sched-ext/scx
>> +
>> +config PREFERRED_CPU
>> + bool
>
> This still should depend on PARAVIRT and SMP. And maybe to enforce it
> even stronger, your driver should fail to build if PREFERRED_CPU is
> disabled. Imagine a scenario when someone makes PREFERRED_CPU
> depending on some other config, but doesn't modify your driver. That
> way you'll build the STEAL_MONITOR successfully, but because
> PREFERRED_CPU is off, you'll end up with non-working functionality at
> best, or corrupted cpu_active_mask at worst.
>
Sorry, i may not understand all the intricacies of kconfigs.
But, Since driver selects PREFERRED_CPU, and PREFERRED_CPU can't be enabled
individually, driver again can't depend on PREFERRED_CPU right?
As per previous discussion, it is probably better that driver selects PREFERRED_CPU.
Keeping them both independent and selectable brings too many variations.
No?
I guess you meant below.
In kernel/Kconfig.preempt:
config PREFERRED_CPU
bool
depends on SMP && PARAVIRT
Driver's Kconfig (this is there already)
config VIRT_STEAL_GOVERNOR
tristate "Virtual Steal Time Governor"
depends on SMP && PARAVIRT
select PREFERRED_CPU
> Also, the name 'steal monitor' implies monitoring, while in fact
> you're actively affecting the scheduling process.
>
> Maybe 'steal governor'?
>
Make sense. Will do.
> Thanks,
> Yury
next prev parent reply other threads:[~2026-07-14 6:31 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 21:56 [PATCH v7 00/12] sched, steal_monitor: Introduce cpu_preferred_mask and steal-driven vCPU backoff Shrikanth Hegde
2026-07-09 21:56 ` [PATCH v7 01/12] sched/docs: Document cpu_preferred_mask and Preferred CPU concept Shrikanth Hegde
2026-07-09 21:56 ` [PATCH v7 02/12] cpumask: Introduce cpu_preferred_mask Shrikanth Hegde
2026-07-13 14:53 ` Yury Norov
2026-07-14 6:30 ` Shrikanth Hegde [this message]
2026-07-14 13:01 ` Yury Norov
2026-07-09 21:56 ` [PATCH v7 03/12] sysfs: Add preferred CPU file Shrikanth Hegde
2026-07-10 15:41 ` Yury Norov
2026-07-10 17:00 ` Shrikanth Hegde
2026-07-10 23:09 ` Yury Norov
2026-07-13 12:00 ` Shrikanth Hegde
2026-07-09 21:56 ` [PATCH v7 04/12] sched/core: Try to use a preferred CPU in is_cpu_allowed Shrikanth Hegde
2026-07-09 21:56 ` [PATCH v7 05/12] sched/fair: Load balance only among preferred CPUs Shrikanth Hegde
2026-07-09 21:56 ` [PATCH v7 06/12] sched/core: Push current task from non preferred CPU Shrikanth Hegde
2026-07-10 23:02 ` Yury Norov
2026-07-13 12:35 ` Shrikanth Hegde
2026-07-09 21:56 ` [PATCH v7 07/12] sched/debug: Add migration stats due to non preferred CPUs Shrikanth Hegde
2026-07-09 21:56 ` [PATCH v7 08/12] virt: Introduce steal monitor driver Shrikanth Hegde
2026-07-10 1:27 ` Randy Dunlap
2026-07-10 4:28 ` Shrikanth Hegde
2026-07-10 20:53 ` Yury Norov
2026-07-13 12:06 ` Shrikanth Hegde
2026-07-09 21:56 ` [PATCH v7 09/12] virt/steal_monitor: Add control knobs for handling steal values Shrikanth Hegde
2026-07-10 4:27 ` Shrikanth Hegde
2026-07-09 21:56 ` [PATCH v7 10/12] virt/steal_monitor: Provide functions for managing " Shrikanth Hegde
2026-07-10 4:30 ` Shrikanth Hegde
2026-07-10 20:00 ` Yury Norov
2026-07-13 5:13 ` Shrikanth Hegde
2026-07-14 12:47 ` Yury Norov
2026-07-14 13:15 ` Shrikanth Hegde
2026-07-09 21:56 ` [PATCH v7 11/12] virt/steal_monitor: Act on steal time periodically and decide on preferred CPUs Shrikanth Hegde
2026-07-10 20:37 ` Yury Norov
2026-07-13 5:48 ` Shrikanth Hegde
2026-07-14 12:31 ` Yury Norov
2026-07-14 13:08 ` Shrikanth Hegde
2026-07-09 21:56 ` [PATCH v7 12/12] sched, virt/steal_monitor: Keep tick on for faster push on nohz_full CPU Shrikanth Hegde
2026-07-10 6:35 ` Shrikanth Hegde
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=df198506-9c6e-4e79-bf3b-798668322708@linux.ibm.com \
--to=sshegde@linux.ibm.com \
--cc=arighi@nvidia.com \
--cc=chleroy@kernel.org \
--cc=christian.loehle@arm.com \
--cc=corbet@lwn.net \
--cc=dietmar.eggemann@arm.com \
--cc=frederic@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=hdanton@sina.com \
--cc=huschle@linux.ibm.com \
--cc=iii@linux.ibm.com \
--cc=juri.lelli@redhat.com \
--cc=kernellwp@gmail.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maddy@linux.ibm.com \
--cc=maz@kernel.org \
--cc=mingo@kernel.org \
--cc=pauld@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=rdunlap@infradead.org \
--cc=rostedt@goodmis.org \
--cc=seanjc@google.com \
--cc=srikar@linux.ibm.com \
--cc=tglx@kernel.org \
--cc=tj@kernel.org \
--cc=tommaso.cucinotta@gmail.com \
--cc=vincent.guittot@linaro.org \
--cc=vineeth@bitbyteword.org \
--cc=vschneid@redhat.com \
--cc=ynorov@nvidia.com \
--cc=yury.norov@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.