Messages in this thread | | | Date | Tue, 17 Jan 2023 04:49:28 -0800 | From | Ricardo Neri <> | Subject | Re: [PATCH v2 1/7] sched/fair: Generalize asym_packing logic for SMT local sched group |
| |
On Mon, Jan 16, 2023 at 07:07:54PM +0000, Valentin Schneider wrote: > On 15/01/23 20:05, Ricardo Neri wrote: > >> > > >> > It should be set on any topology level below the NUMA ones, we do remove it > >> > on SD_ASYM_CPUCAPACITY levels because this used to interfere with misfit > >> > balancing (it would override the group_type), things are a bit different > >> > since Vincent's rewrite of load_balance() but I think we still want it off > >> > there. > > > > Your comment got me thinking. Whose child sched domain wants prefer_sibling? > > It sounds to me that is busiest's. I could not think of any reason of *having* > > to use the flags of the local group. > > > > Hm, given that on systems without SD_ASYM_CPUCAPACITY, SD_PREFER_SIBLING is > set all the way from SMT up to the last !NUMA domain, should we just get > rid of the child/parent weirdness of SD_PREFER_SIBLING and stick with the > flags we are given at the level we're balancing at? > > i.e. > > sds->prefer_sibling = env->sd & SD_PREFER_SIBLING;
Agreed. This would also make the code easier to understand. It should not change the current behavior either; except (i.e., fix) for the busiest->group_weight = 2 vs local->group_weight = 1 I raised.
> > Unless I'm reading this wrong, this also eliminates the effect of > SD_PREFER_SIBLING on the first NUMA level - DIE level has SD_PREFER_SIBLING > set, but we don't necessarily want to evenly spread things out when accross > NUMA nodes.
Agreed.
> > > > We can use the flags of the sched group (as per 16d364ba6ef2 ("sched/topology: > > Introduce sched_group::flags"), these are the flags of the child domain). > > > > The patch below works for me and I don't have to even the number of busy CPUs. > > It should not interfere with misfit balancing either: > > > > We remove that flag on systems where misfit balancing happens anyway, so > that's safe vs. SD_PREFER_SIBLING.
Then all looks good with your suggestion. I'll include a patch in my series.
Thanks and BR, Ricardo
| |