Messages in this thread | | | Date | Wed, 4 Oct 2023 11:23:41 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH v4] sched/core: Use zero length to reset cpumasks in sched_setaffinity() |
| |
* Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, Oct 03, 2023 at 04:57:35PM -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 input cpumask length of 0 to signal a reset of the cpumasks > > to the default as allowed by the current cpuset. A non-NULL cpumask > > should still be provided to avoid problem with older kernel. > > > > If sched_setaffinity(2) has been called previously to set a user > > supplied cpumask, a value of 0 will be returned to indicate success. > > Otherwise, an error value of -EINVAL will be returned. > > > > We may have to update the sched_setaffinity(2) manpage to document > > this new side effect of passing in an input length of 0. > > Bah.. so while this is less horrible than some of the previous hacks, > but I still think an all set mask is the sanest option. > > Adding FreeBSD's CPU_FILL() to glibc() isn't the hardest thing ever, but > even without that, it's a single memset() away. > > > Would not the below two patches, one kernel, one glibc, be all it takes?
I'd much prefer this ABI variant, it's a pretty natural extension of the existing ABI and principles:
> if (user_mask) { > - cpumask_copy(user_mask, in_mask); > + /* > + * All-set user cpumask resets affinity and drops the explicit > + * user mask. > + */ > + cpumask_and(user_mask, in_mask, cpu_possible_mask); > + if (cpumask_equal(user_mask, cpu_possible_mask)) { > + kfree(user_mask); > + user_mask = NULL; > + }
Question: is there any observable behavioral difference between current (old) all-set cpumask calls and the patched (new) one?
Thanks,
Ingo
| |