Messages in this thread | | | Date | Tue, 15 Mar 2022 18:18:59 +0100 | Subject | Re: [PATCH] sched: dynamic config sd_flags if described in DT | From | Dietmar Eggemann <> |
| |
On 15/03/2022 08:58, Qing Wang wrote: > From: Wang Qing <wangqing@vivo.com>
(1) Can you share more information about your CPU topology?
I guess it is a single DSU (DynamIQ Shared Unit) ARMv9 system with 8 CPUs? So L3 spans over [CPU0..CPU7].
You also mentioned complexes. Am I right in assuming that [CPU0..CPU3] are Cortex-A510 cores where each 2 CPUs share a complex?
What kind of uarch are the CPUs in [CPU4..CPU7]? Are they Cortex-A510's as well? I'm not sure after reading your email:
https://lkml.kernel.org/r/SL2PR06MB30828CF9FF2879AFC9DC53D2BD0C9@SL2PR06MB3082.apcprd06.prod.outlook.com
You might run into the issue that individual CPUs of your system see a different SD hierarchy in case that [CPU4..CPU7] aren't Cortex-A510's, i.e. CPUs not sharing complexes.
(2) Related to your MC Sched Domain (SD) layer:
If you have a single DSU ARMv9 system, then in Linux kernel mainline you shouldn't have sub-clustering of [CPU0..CPU3] and [CPU4...CPU7].
I.e. the cpu-map entry in your dts file should only list cores, not clusters.
I know that in Android the cluster entries are used to sub-group different uarch CPUs in an asymmetric CPU capacity system (a.k.a. Arm DynamIQ and Phantom domains) but this is eclipsing the true L3 (LLC) information and is not "supported" (in the sense of "used") in mainline.
But I have a hard time to see what [CPU0..CPU3] or [CPU4..CPU7] are shareing in your system.
(3) Why do you want this different SD hierarchy?
I assume in mainline your system will have a single SD which is MC (w/o the Phantom domain approach from Android).
You mentioned cpus_share_cache(). Or is it the extra SD level which changes the behaviour of CFS load-balancing? I'm just wondering since EAS wouldn't be affected here. I'm sure I can understand this better once we know more about your CPU topology.
[...]
| |