On Tuesday 15 Oct 2019 at 11:22:12 (+0200), 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. Right, and we want something similar for the asym static key I think. That is, it should be enabled if _at least one_ RD is asymmetric. > Valentin's patch makes sure that sched_asym_cpucapacity is correctly set > when the sd hierarchy is rebuild due to CPU hp. As mentioned in a previous email, I think this patch is broken in case you have multiple asymmetric RDs, but counting should fix it, though it might not be that easy to implement. > 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. I'm not sure what you meant here ? > 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. > > 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. Right, that's already true today, and I don't see a possible alternative to that. Same thing for the EAS static key and the pd list btw. Thanks, Quentin
