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

[Yury Norov]

On Mon, Nov 02, 2026 at 09:47:04AM +0100, Peter Zijlstra wrote:
> 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.

OK, I started with the wrong argument. Please consider this as the argument
#3.

#1 is: conceptually, preferred cpumask improves performance because it
moves the scheduling decision from host to the guest level. The guest
can do it better because it knows more about the workload. But then we'd
consider moving steal governor logic to the guest userspace, because it
knows the nature of user workload even more.

#2: convenience and scope. Some systems don't allow loading modules -
either on config level, through selinux, or somehow else. They don't
even have compiler installed sometimes. The sysfs, on the other hand,
is typically available.

I want to be able to write a simple userspace daemon that implements
steal governing without loading any modules; and i want to be able to
tailor my daemon to my specific workload. That all requires write
interface.

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

Then why do we need the steal governor at all? We can steer all
processes away from a given vCPU without any driver, only by playing
with each individual process' affinity. For vCPU throttling, task
isolation, or whatever purpose.

Because of the overhead and convenience to use. Setting an explicit
affinity for each task would require preserving the original cpumask,
not mentioning that it's much more invasive.

The overhead grows linearly with the number of threads. On my working
station right now the number of processes is over 500, and number of
threads is over 1500, and it runs pretty much idle.

This is so impractical that people would rather use boot-time isolcpus,
not to mess with thousands of individual affinities on runtime.
 
> > 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.

OK, that's fair. I can make it mutually exclusive. 

Thanks,
Yury