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

[Peter Zijlstra <peterz@infradead.org>]

On Tue, Oct 03, 2023 at 02:58:58PM -0400, Waiman Long wrote:
> 
> 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.

Blergh, FreeBSD has CPU_FILL(), but it appears we don't have this.

Still, nothing a memset can't fix. CPU_ZERO() ends up in
__builtin_memset() too. I'm sure our glibc boys can add CPU_FILL()
eventually.

Anyway, I see you sent a v4, I'll go look at that in the am, sleep now.