Re: [PATCH 0/6] sched: Expose writable interface for preferred CPUs mask

[Shrikanth Hegde]

On 11/11/26 11:11 PM, Yury Norov wrote:
> On Tue, Nov 10, 2026 at 02:45:58PM +0530, Shrikanth Hegde wrote:
> > Hi,
> >
> > On 11/10/26 8:45 AM, Maxim Kuvyrkov wrote:
> > > > On Nov 2, 2026, at 08:21, Yury Norov <ynorov@xxxxxxxxxx> wrote:
> > > >
> > > > The preferred CPU mask currently lets the steal governor reduce vCPU
> > > > demand when physical CPUs are contended. This series adds manual control,
> > > > opening more use cases.
> > > >
> > > > For example, setting CPUs aside for selected fair tasks at runtime while
> > > > steering other fair tasks toward the remaining CPUs.
> > >
> > > Hi Yury,
> > >
> > > I've been trying to do this with crutches in user-space for a long time.  Thanks for implementing this in the kernel, and with a convenient user interface.
> > >
> > > > A user can mark a CPU non-preferred and pin a workload to it. Fair tasks
> > > > whose affinity includes preferred CPUs are steered away, while tasks
> > > > whose allowed CPUs contain no preferred CPU can still run there. The CPU
> > > > stays online, task affinity is preserved, and the selection can be
> > > > reversed without rebooting:
> > > >
> > > >      # rmmod steal_governor
> > > >      # echo 0 > /sys/devices/system/cpu/cpu3/preferred
> > > >      # taskset -c 3 ./my_workload
> > > >      # echo 1 > /sys/devices/system/cpu/cpu3/preferred
> > >
> > > My use-case (being a compiler optimization engineer) is to pin benchmarks to specific cores, and stop the system from using those cores even when the cores are idle.  This prevents L1/L2 cache pollution and makes performance numbers more stable.
> >
> > Do you change it when running workload based on any signal/event? or you set it before starting it?
> >
> > If it is set before starting, you might as well offline the CPUs to achieve the same. I assume you are
> > managing the preferred CPUs manually with write interface. You can do the same for online state.
> > (Though it takes a longer)
>
> How that? I tried, and offlining destroys the affinity, as it should:

You are doing "hotplug when workload is running".

>    # taskset -c 3 sh -c 'while :; do :; done' &
>    [1] 380
>    # taskset -pc "$pid"
>    pid 380's current affinity list: 3
>    # echo 0 >/sys/devices/system/cpu/cpu3/online
>    [  115.767634] process 380 (sh) no longer affine to cpu3
>    [  115.772881] smpboot: CPU 3 is now offline
>    taskset -pc 380
>    pid 380's current affinity list: 0-2,4-7
>
> Did you mean something else, maybe?

What matters is how/when you start the workload.
From the use case, I see it is about using only specific set of CPUs and there is no explicit affinity assigned.

Sequence1:
1. You are setting preferred CPUs.
2. You start the workload. Workload finishes using preferred CPUs.
3. You set the preferred same as active.

In that sequence, offlining the CPUs is going to be similar. You are managing preferred CPUs, you can as well manage
offline CPUs. Most of the workload check the CPU state before assigning any explicit affinity or spawning threads etc.

Sequence 2:
1. workload is long running job. Lets say comprising of warmup/steady/closure phases.
2. You only to run on specific CPUs during steady phase.
3. You fallback to active during closure phase again.

In that sequence what you said about offline breaking affinities is very much possibility. It is
good to set preferred CPUs in this sequence.

but reading maxim's description it fitted Sequence1.