linux-kernel - Re: [RFC PATCH] sched/fair: Fix impossible migrate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1e675286-b4b8-5abd-dd4c-3f2ffdaf12c1@arm.com>
Date:   Mon, 24 Jul 2023 19:54:50 +0200
From:   Dietmar Eggemann <dietmar.eggemann@....com>
To:     Qais Yousef <qyousef@...alina.io>
Cc:     Vincent Guittot <vincent.guittot@...aro.org>,
        Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH] sched/fair: Fix impossible migrate_util scenario in
 load balance

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.

[...]