Messages in this thread | | | Subject | Re: [PATCH] sched/arm64: store cpu topology before notify_cpu_starting | From | "chengjian (D)" <> | Date | Mon, 6 Apr 2020 16:00:32 +0800 |
| |
On 2020/4/1 21:23, Valentin Schneider wrote: > (+LAKML, +Sudeep) > > On Wed, Apr 01 2020, Cheng Jian wrote: >> when SCHED_CORE enabled, sched_cpu_starting() uses thread_sibling as >> SMT_MASK to initialize rq->core, but only after store_cpu_topology(), >> the thread_sibling is ready for use. >> >> notify_cpu_starting() >> -> sched_cpu_starting() # use thread_sibling >> >> store_cpu_topology(cpu) >> -> update_siblings_masks # set thread_sibling >> >> Fix this by doing notify_cpu_starting later, just like x86 do. >> > I haven't been following the sched core stuff closely; can't this > rq->core assignment be done in sched_cpu_activate() instead? We already > look at the cpu_smt_mask() in there, and it is valid (we go through the > entirety of secondary_start_kernel() before getting anywhere near > CPUHP_AP_ACTIVE). > > I don't think this breaks anything, but without this dependency in > sched_cpu_starting() then there isn't really a reason for this move.
Yes, it is correct to put the rq-> core assignment in sched_cpu_active().
The cpu_smt_mask is already valid here.
I have made such an attempt on my own branch and passed the test.
Thank you.
-- Cheng Jian
| |