(+LAKML, +Sudeep)
On Wed, Apr 01 2020, Cheng Jian wrote:
when SCHED_CORE enabled, sched_cpu_starting() uses thread_sibling asI haven't been following the sched core stuff closely; can't this
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.
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.