Messages in this thread | | | Date | Tue, 3 Oct 2023 23:48:22 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH v3] sched/core: Use empty mask to reset cpumasks in sched_setaffinity() |
| |
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.
| |