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

[Peter Zijlstra <peterz@infradead.org>]

On Sun, Nov 01, 2026 at 02:21:56PM -0500, Yury Norov 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.

Sceptical, I am.

> For example, setting CPUs aside for selected fair tasks at runtime while
> steering other fair tasks toward the remaining CPUs.

That's exactly the kind of nonsense we don't need and makes me want to
stop reading right here.

We already have cpusets that is more than capable of doing this.

> 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
> 
> The current preferred list is still readable from:
> 
>     /sys/devices/system/cpu/preferred
> 
> This provides task-placement isolation similar to a use of
> isolcpus=domain, with a runtime interface. Scheduling domains remain
> intact, tick suppression, RCU offloading, and managed-IRQ avoidance
> can be configured separately when needed.
> 
> Different preferred cpumask governors may coexist; all update the
> same mask under common locking. Manual settings are not privileged,
> and later governor updates may override them.

That is a recipe for disaster.

Don't bother trying again, this isn't happening.