pytorch
Parse error when we set arm64's cpus to one cluster for DynamIQ arch
ecause DynamIQ allows for more diverse core configurations within the same cluster, and even enables the mixing of cores with different performance levels. In fact, they belong to the same physical cluster. Currently, our SoC is configured with 6 A55 cores (0-5) and 2 A78 cores (6-7). and the CPU can be configured as follows in the device tree:
cpu-map {
cluster0 {
core0 {
cpu = <&CPU0>;
};
core1 {
cpu = <&CPU1>;
};
core2 {
cpu = <&CPU2>;
};
core3 {
cpu = <&CPU3>;
};
core4 {
cpu = <&CPU4>;
};
core5 {
cpu = <&CPU5>;
};
core6 {
cpu = <&CPU6>;
};
core7 {
cpu = <&CPU7>;
};
};
};
As a result: the cpuinfo will parse the cpu as follow：
SoC name: Unknown Microarchitectures: 8x Cortex-A55 Cores: 0: 1 processor (0), ARM Cortex-A55 1: 1 processor (1), ARM Cortex-A55 2: 1 processor (2), ARM Cortex-A55 3: 1 processor (3), ARM Cortex-A55 4: 1 processor (4), ARM Cortex-A55 5: 1 processor (5), ARM Cortex-A55 6: 1 processor (6), ARM Cortex-A55 7: 1 processor (7), ARM Cortex-A55 Clusters: 0: 8 processors (0-7), 0: 8 cores (0-7), ARM Cortex-A55 Logical processors (System ID): 0 (0) 1 (1) 2 (2) 3 (3) 4 (4) 5 (5) 6 (6) 7 (7)
This is because the cluster_cpus is all ff: cat /sys/devices/system/cpu/cpu*/topology/cluster_cpus ff ff ff ff ff ff ff ff
As a result, we must set the devices tree as following:
cpu-map {
cluster0 {
core0 {
cpu = <&CPU0>;
};
core1 {
cpu = <&CPU1>;
};
core2 {
cpu = <&CPU2>;
};
core3 {
cpu = <&CPU3>;
};
core4 {
cpu = <&CPU4>;
};
core5 {
cpu = <&CPU5>;
};
};
cluster1 {
core0 {
cpu = <&CPU6>;
};
core1 {
cpu = <&CPU7>;
};
};
};
When set this, the cpuinfo's result is true:
Microarchitectures: 2x Cortex-A78 6x Cortex-A55 Cores: 0: 1 processor (0), ARM Cortex-A78 1: 1 processor (1), ARM Cortex-A78 2: 1 processor (2), ARM Cortex-A55 3: 1 processor (3), ARM Cortex-A55 4: 1 processor (4), ARM Cortex-A55 5: 1 processor (5), ARM Cortex-A55 6: 1 processor (6), ARM Cortex-A55 7: 1 processor (7), ARM Cortex-A55 Clusters: 0: 2 processors (0-1), 0: 2 core (0-1), ARM Cortex-A78 1: 6 processors (2-7), 1: 6 cores (2-7), ARM Cortex-A55 Logical processors (System ID): 0 (6) 1 (7) 2 (0) 3 (1) 4 (2) 5 (3) 6 (4) 7 (5)
This is because the following code:
for (uint32_t i = 0; i < arm_linux_processors_count; i++) { if (bitmask_all(arm_linux_processors[i].flags, CPUINFO_LINUX_FLAG_VALID)) { const uint32_t cluster_leader = arm_linux_processors[i].package_leader_id; if (cluster_leader == i) { / Cluster leader: decode core vendor and uarch / cpuinfo_arm_decode_vendor_uarch( arm_linux_processors[cluster_leader].midr, #if CPUINFO_ARCH_ARM !!(arm_linux_processors[cluster_leader].features & CPUINFO_ARM_LINUX_FEATURE_VFPV4), #endif &arm_linux_processors[cluster_leader].vendor, &arm_linux_processors[cluster_leader].uarch); } else { / Cluster non-leader: copy vendor, uarch, MIDR, * and frequency from cluster leader / arm_linux_processors[i].flags |= arm_linux_processors[cluster_leader].flags & (CPUINFO_ARM_LINUX_VALID_MIDR | CPUINFO_LINUX_FLAG_MAX_FREQUENCY); arm_linux_processors[i].midr = arm_linux_processors[cluster_leader].midr; arm_linux_processors[i].vendor = arm_linux_processors[cluster_leader].vendor; arm_linux_processors[i].uarch = arm_linux_processors[cluster_leader].uarch; arm_linux_processors[i].max_frequency = arm_linux_processors[cluster_leader].max_frequency; } } }
Because the clusters's cpus is 0-7, so it set cpu0 as the leader,and all other cpus copy the cpu0's feature, indeed, this is not true.
Thanks!
I guess the solution would be to not use leader as a representative for the cpus in topology/cluster_cpus, because the assumption that there is always homogeneous cores inside a cluster isn't valid for your SoC?
Would you be open to a PR with a mock test for your SoC?
I guess the solution would be to not use leader as a representative for the cpus in
topology/cluster_cpus, because the assumption that there is always homogeneous cores inside a cluster isn't valid for your SoC?
Yes， you are right.
Would you be open to a PR with a mock test for your SoC?
It's my honor, and I would be more than happy to provide the corresponding tests.
Thanks!
@xw-yan I would be interested in a fix, too. Did you have a chance to look into the issue and address the problem with the cluster_leader in heterogenious systems?
