On Tue, 9 Feb 2021 at 12:46, Valentin Schneider valentin.schneider@arm.com wrote:
On 09/02/21 10:46, Vincent Guittot wrote:
On Tue, 9 Feb 2021 at 09:27, Barry Song song.bao.hua@hisilicon.com 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