You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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!
The text was updated successfully, but these errors were encountered:
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.
@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?
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:
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:
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!
The text was updated successfully, but these errors were encountered: