Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
sched: Store restrict_cpus_allowed_ptr() call state
The user_cpus_ptr field was originally added by commit b90ca8b ("sched: Introduce task_struct::user_cpus_ptr to track requested affinity"). It was used only by arm64 arch due to possible asymmetric CPU setup. Since commit 8f9ea86 ("sched: Always preserve the user requested cpumask"), task_struct::user_cpus_ptr is repurposed to store user requested cpu affinity specified in the sched_setaffinity(). This results in a slight performance regression on an arm64 system when booted with "allow_mismatched_32bit_el0" on the command-line. The arch code will (amongst other things) calls force_compatible_cpus_allowed_ptr() and relax_compatible_cpus_allowed_ptr() when exec()'ing a 32-bit or a 64-bit task respectively. Now a call to relax_compatible_cpus_allowed_ptr() will always result in a __sched_setaffinity() call whether there is a previous force_compatible_cpus_allowed_ptr() call or not. In order to fix this regression, a new scheduler flag task_struct::cpus_allowed_restricted is now added to track if force_compatible_cpus_allowed_ptr() has been called before or not. This patch also updates the comments in force_compatible_cpus_allowed_ptr() and relax_compatible_cpus_allowed_ptr() and handles their interaction with sched_setaffinity(). This patch also removes the task_user_cpus() helper. In the case of relax_compatible_cpus_allowed_ptr(), cpu_possible_mask as user_cpu_ptr masking will be performed within __sched_setaffinity() anyway. Fixes: 8f9ea86 ("sched: Always preserve the user requested cpumask") Reported-by: Will Deacon <will@kernel.org> Signed-off-by: Waiman Long <longman@redhat.com>
- Loading branch information