On 15/10/2019 10:22, Dietmar Eggemann wrote: > I still don't understand the benefit of the counter approach here. > sched_smt_present counts the number of cores with SMT. So in case you > have 2 SMT cores with 2 HW threads and you CPU hp out one CPU, you still > have sched_smt_present, although 1 CPU doesn't have a SMT thread sibling > anymore. > > Valentin's patch makes sure that sched_asym_cpucapacity is correctly set > when the sd hierarchy is rebuild due to CPU hp. Including the unlikely > scenario that an asymmetric CPU capacity system (based on DT's > capacity-dmips-mhz values) turns normal SMT because of the max frequency > values of the CPUs involved. > > Systems with a mix of asymmetric and symmetric CPU capacity rd's have to > live with the fact that wake_cap and misfit handling is enabled for > them. This should be the case already today. > Good point, that's what I slowly came to realize this morning. > There should be no SD_ASYM_CPUCAPACITY flag on the sd's of the CPUs of > the symmetric CPU capacity rd's. I.e. update_top_cache_domain() should > set sd_asym_cpucapacity=NULL for those CPUs. > > So as a rule we could say even if a static key enables a code path, a > derefenced sd still has to be checked against NULL. > Yeah, I think there's no escaping it. Let me see if I can do something sensible regarding the static key.
