Re: [PATCH] sched/core: Use empty mask to reset cpumasks in sched_setaffinity()

[Waiman Long <longman@redhat.com>]

On 7/5/23 05:37, Peter Zijlstra wrote:
> On Mon, Jul 03, 2023 at 10:55:02AM -0400, Waiman Long wrote:
>
>> Our OpenShift team has actually hit a problem with the recent persistent
>> user provided cpu affinity change because they are relying on the fact that
>> moving a task to a different cpuset will reset cpu affinity to the cpuset
>> default which is no longer true. That is the main reason behind this patch
>> to provide a way to reset cpu affinity to the cpuset default.
> Where is the sched_setaffinity() in that story?
>
> So somewhere this thing did a sched_setaffinity() and then starts
> playing with cpusets. Instead of adding more sched_setaffinity() calls,
> can't it just remove some?

I don't know the full picture. From what I understand, there is a master 
control process that limit its cpu affinity to just a limited set of 
housekeeping CPUs. It then spawn child processes to be run in different 
containers. The control process doesn't need to change its cpu affinity.

In the past, putting the child processes in a different container 
(cpuset) will reset its affinity to that of the cpuset. That is not true 
anymore because user_cpus_ptr is inherited in the forked child process. 
I have thought about 2 ways to address that. Either we introduce a new 
clone flag to disable the inheritance of users_cpu_ptr or a way to reset 
the cpu affinity to the default which is what this patch does.

Cheers,
Longman