Messages in this thread | | | Date | Mon, 30 Jan 2023 14:05:33 -0500 | Subject | Re: [PATCH v3] sched: Store restrict_cpus_allowed_ptr() call state | From | Waiman Long <> |
| |
On 1/30/23 06:56, Peter Zijlstra wrote: > On Thu, Jan 26, 2023 at 08:55:27PM -0500, Waiman Long wrote: >> The user_cpus_ptr field was originally added by commit b90ca8badbd1 >> ("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 8f9ea86fdf99 ("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" > Dude, how can you still call this a slight performance regression after > Will told you time and time again that's not the problem. > > It clearly is a behavioural problem.
I am trying to figure out if this behavioral problem is a result of my scheduler patch or just as a result of cgroup v1 current behavior as I don't see how my patch will cause this behavioral change if it is not an existing problem.
Cheers, Longman
| |