Re: [RFC PATCH] sched/fair: Fix impossible migrate_util scenario in load balance

[Dietmar Eggemann <dietmar.eggemann@arm.com>]

On 24/07/2023 18:10, Qais Yousef wrote:
> On 07/24/23 14:58, Dietmar Eggemann wrote:
>> On 22/07/2023 00:04, Qais Yousef wrote:
>>> On 07/21/23 15:52, Vincent Guittot wrote:
>>>> Le vendredi 21 juil. 2023 à 11:57:11 (+0100), Qais Yousef a écrit :
>>>>> On 07/20/23 14:31, Vincent Guittot wrote:

[...]

> So I actually moved everything to a single cluster and this indeed solves the
> lb() issue. But then when I tried to look at DT mainline I saw that the DTs
> still define separate cluster for each uArch, and this got me confused whether
> I did the right thing or not. And made me wonder whether the fix is to change
> DT or port Sudeep's/Ionela's patch?

IMHO, you have to change DT.

> I did some digging and I think the DT, like the ones in mainline by the look of
> it, stayed the way it was historically defined.

This would be a "mistake" for Arm DynamIQ based systems. We use QC RB5
in our testing and this board schedules only within a MC sched domain (I
guess it's: arch/arm64/boot/dts/qcom/qrb5165-rb5.dts -> sm8250.dtsi)

> So IIUC the impacts are on system pre-simplified EM (should have been phased
> out AFAIK). And on different presentation on sysfs topology which can
> potentially break userspace deps, right? I think this is not a problem too, but
> can be famous last words as usual :-)

The only thing I remember was when we hinted at this issue to Android
folks a couple of years ago, they said they have to stay with the
phantom domain due to dependencies from vendor specific code other than
related to the EM.

IMHO, for Pixel6 the DT cpu-map information is in:

  private/gs-google/arch/arm64/boot/dts/google/gs101-cpu.dtsi

of the android-kernel.

[...]