On Tue, 9 Feb 2021 at 12:46, Valentin Schneider <[email protected]> wrote: > > On 09/02/21 10:46, Vincent Guittot wrote: > > On Tue, 9 Feb 2021 at 09:27, Barry Song <[email protected]> wrote: > >> Real servers which suffer from this problem include Kunpeng920 and 8-node > >> Sun Fire X4600-M2, at least. > >> > >> Here we move to use the *child* domain of the *child* domain of node2's > >> domain2 as the new added sched_group. At the same, we re-use the lower > >> level sgc directly. > > > > Have you evaluated the impact on the imbalance and next_update fields ? > > > > sgc->next_update is safe since it's only touched by CPUs that have the > group span as local group (which is never the case for CPUs where we do > this "grandchildren" trick).
It would be good to explain this in the commit message > > I'm a bit less clear about sgc->imbalance. I think it can be set by remote > CPUs, but it should only be cleared when running load_balance() by CPUs > that have that group span as local group, as per: > > int *group_imbalance = &sd_parent->groups->sgc->imbalance; We are also safe because sd_parent remains the same as the beg of load_balance and LB only tries other CPUs from the local group
