Messages in this thread | | | Date | Fri, 21 Jul 2023 11:42:33 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH v2] sched/core: Use empty mask to reset cpumasks in sched_setaffinity() |
| |
On Mon, Jul 17, 2023 at 02:02:43PM -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. > > Before this patch, passing in an empty cpumask to sched_setaffinity(2) > will always return an EINVAL error. With this patch, an error will no > longer be returned if sched_setaffinity(2) has been called before to > set up user_cpus_ptr. Instead, the user_cpus_ptr that stores the user > provided affinity will be cleared and the task's CPU affinity will be > reset to that of the current cpuset. No error will be returned in this > case to signal that a reset has happened. > > If sched_setaffinity(2) has not been called previously, an EINVAL error > will be returned with an empty cpumask just like before. As a result, > tests or tools that rely on this behavior will not be affected unless > they have somehow called sched_setaffinity(2) before. > > We will have to update the sched_setaffinity(2) manpage to document > this possible side effect of passing in an empty cpumask.
So a normal task, that hasn't had it's affinity changed will have possible_mask.
So why not use in_mask == possible_mask to clear the user state?
| |