Skip to content

Parse error when we set arm64's cpus to one cluster for DynamIQ arch #280

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
xw-yan opened this issue Feb 24, 2025 · 3 comments
Open

Parse error when we set arm64's cpus to one cluster for DynamIQ arch #280

xw-yan opened this issue Feb 24, 2025 · 3 comments

Comments

@xw-yan
Copy link

xw-yan commented Feb 24, 2025

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!

@digantdesai
Copy link
Contributor

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?

@xw-yan
Copy link
Author

xw-yan commented Feb 25, 2025

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!

@atusnr
Copy link

atusnr commented Apr 16, 2025

@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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants