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

From: Waiman Long
Date: Tue Oct 03 2023 - 14:59:52 EST



On 10/3/23 06:06, Peter Zijlstra wrote:
On Thu, Aug 03, 2023 at 10:32:18PM -0400, Waiman Long wrote:
Since commit 8f9ea86fdf99 ("sched: Always preserve the user requested
cpumask"), user provided CPU affinity via sched_setaffinity(2) is
perserved even if the task is being moved to a different cpuset. However,
that affinity is also being inherited by any subsequently created child
processes which may not want or be aware of that affinity.

One way to solve this problem is to provide a way to back off from
that user provided CPU affinity. This patch implements such a scheme
by using an empty cpumask to signal a reset of the cpumasks to the
default as allowed by the current cpuset.
So I still don't like this much, the normal state is all bits set:

$ grep allowed /proc/self/status
Cpus_allowed: ff,ffffffff

The all clear bitmask just feels weird for this.

The main reason for using an empty bitmask is the presence of the CPU_ZERO() macro that can produce this empty cpumask. It is certainly possible to use an all set bitmask for reset purpose. The only problem is it is more complicated to generate such a bitmask as there is no existing CPU* macros that can be used.

Another possible alternative is to use a cpusetsize of 0 to indicate a reset as long as it doesn't cause problem with existing code. Will that be acceptable?

Cheers,
Longman