Implement CPU Cluster information

[Richy-Z]

I propose the inclusion of CPU cluster information in order to enhance the recognition of heterogeneous architectures on macOS. My recent observation on Windows revealed distinct clusters based on core types, with Cluster 1 for Performance Cores and Cluster 2 for Efficiency Cores.

Though I lack deep insight into Intel's new core configuration, I suggest investigating the feasibility of introducing cluster information as it might not only offer potential performance benefits but also serve as a valuable cosmetic feature for people like me who seek a more detailed view of their CPU architecture.

As an example, CpuTopologyRebuild currently places 8 cores in Cluster 1 with the -ctrsmt boot argument (acknowledging that it involves 8 cores with the efficiency cores being logical threads of the performance cores) for my Intel Core i9-14900KF. In Windows (non-OpenCore, standard boot), Cluster 1 encompasses the performance cores (8 of them), while Cluster 2 comprises the efficiency cores (16 of them).

Cluster information in macOS using Geekbench

Cluster information in Windows using Geekbench

While Apple's M series chips have native support for clusters, it raises questions about whether macOS inherently supports clusters based on specific processor types. It's conceivable that cluster support is embedded in the kernel, as the kernel needs to adeptly handle different core types and configurations. However, this might just be locked to M series chips. If not, then this would be absolutely amazing for use with Intel's newer CPU's as then macOS would be able to differentiate Performance Cores from Efficiency Cores and actually handle them accordingly (potentially)

Cluster information about an M3 Max in macOS using Geekbench

Again, my knowledge on how the CPU topology is handled in macOS is limited, and especially Intel's new Performance+Efficiency cores. - this is just a very (probably stupid) suggestion

If this isnt a stupid suggestion though, I'm open to providing my system as a testing platform.
Intel Core i9-14900KF (8 Performance + 16 Efficiency (24c total), 32 threads)
AMD Radeon RX 6900 XT (XTXH Variant)
Full specifications available on GitHub

Also I looked up how macOS manages the performance and efficiency cores with the M series chips and found some interesting information.

https://mjtsai.com/blog/2022/04/25/how-macos-manages-m1-cpu-cores/

macOS doesn’t provide direct access to cores, core types, or clusters, at least not in public APIs. Instead, these are normally managed through Grand Central Dispatch using Quality of Service (QoS) settings, which macOS then uses to determine thread management policies.

macOS strategy is to load E cores heavily with system tasks, and spare P cores for user tasks. This ensures the user is unaware of and unaffected by heavy system workloads. It also minimises battery use in notebooks.

[b00t0x]

I have no knowledge of how Cluster is implemented on the macOS kernel, but it's interesting to see that it's supported, at least on Apple Silicon.
I'm still using the i9-12900KF and also recently purchased an M2 Pro Mac mini, so I'll see what I can do. I don't think it's likely that anything will come of it, but it's worth considering.

[Richy-Z]

To be honest, I just realised that separating cores into their respective clusters would probably be better done through ACPI Patches (.aml files in OpenCore) that changes some properties of the Device objects on these newer Intel chips. If so, then the utility of this kext still wouldn't be entirely replaced by the ACPI patching. Instead, I believe that this kext could work alongside the ACPI patch to maybe spoof or enable the recognition of the new big.LITTLE microarchitecture of Intel chips by the kernel through injection.

[b00t0x]

It's conceivable that cluster support is embedded in the kernel, as the kernel needs to adeptly handle different core types and configurations.

It is true, but

However, this might just be locked to M series chips.

Unfortunately it might be also true.

For arm CPU, cpu_cluster_type and cpu_cluster_id are defined.
https://github.com/apple-oss-distributions/xnu/blob/rel/xnu-10002/osfmk/arm/cpu_data_internal.h#L205-L206
As you expected, cluster_type_t is defined to differentiate between P and E cores.
https://github.com/apple-oss-distributions/xnu/blob/rel/xnu-10002/osfmk/arm/machine_routines.h#L263-L268

However, cluster_type_t for i386 CPUs does not have P and E core definitions and is fixed to CLUSTER_TYPE_SMP. Also, cluster_type_t doesn't seem to be actually used on i386.
https://github.com/apple-oss-distributions/xnu/blob/rel/xnu-10002/osfmk/i386/machine_routines.h#L144-L148
https://github.com/apple-oss-distributions/xnu/blob/rel/xnu-10002/osfmk/i386/machine_routines.c#L661
https://github.com/apple-oss-distributions/xnu/blob/rel/xnu-10002/osfmk/arm/machine_routines_common.c#L1302

cpu_data_t has no information about cluster.
https://github.com/apple-oss-distributions/xnu/blob/rel/xnu-10002/osfmk/i386/cpu_data.h#L172-L345

From these things, it seems that the concept of cluster has not been introduced in i386. ACPI patching also may not to be used for building a cluster.

By the way, for example, in the case of i9-12900KF (8P+8E), it might considered building a dual-processor topology with an 8c16t processor and an 8c8t processor. The kernel is expected to prioritize the primary processor to optimize memory access latency.
However, dual socket cMP operates with interleaving rather than NUMA, and when I previously built a dual Xeon E5 Hackintosh, I could not get good performance with NUMA, so even if I built a dual processor topology, the kernel may not be able to handle threads properly for performance improve.

[Richy-Z]

Whilst this idea seems INCREDIBLY BAD and unconventional, it might be possible to add support for the detection of different processor core types in the xnu kernel (right where there is a comment stating the lack of support for multiple core types by Intel, in the code), rebuild the kernel and then just use it with macOS. I do know it is possible to use your own compiled xnu kernel with macOS but with SIP off, etc. But I think this idea just stretches way too far and is beyond the scope of what this kext should be in the first place. I think it would just be easier to differentiate core types and put them into clusters using an ACPI patch and then just use the kext to handle/manage the CPU that has been modified by the ACPI patch.

[Richy-Z]

Oops, didnt mean to close.

[Pain-and-Love]

I propose the inclusion of CPU cluster information in order to enhance the recognition of heterogeneous architectures on macOS. My recent observation on Windows revealed distinct clusters based on core types, with Cluster 1 for Performance Cores and Cluster 2 for Efficiency Cores.

Though I lack deep insight into Intel's new core configuration, I suggest investigating the feasibility of introducing cluster information as it might not only offer potential performance benefits but also serve as a valuable cosmetic feature for people like me who seek a more detailed view of their CPU architecture.

As an example, CpuTopologyRebuild currently places 8 cores in Cluster 1 with the -ctrsmt boot argument (acknowledging that it involves 8 cores with the efficiency cores being logical threads of the performance cores) for my Intel Core i9-14900KF. In Windows (non-OpenCore, standard boot), Cluster 1 encompasses the performance cores (8 of them), while Cluster 2 comprises the efficiency cores (16 of them).

Cluster information in macOS using Geekbench

Cluster information in Windows using Geekbench

While Apple's M series chips have native support for clusters, it raises questions about whether macOS inherently supports clusters based on specific processor types. It's conceivable that cluster support is embedded in the kernel, as the kernel needs to adeptly handle different core types and configurations. However, this might just be locked to M series chips. If not, then this would be absolutely amazing for use with Intel's newer CPU's as then macOS would be able to differentiate Performance Cores from Efficiency Cores and actually handle them accordingly (potentially)

Cluster information about an M3 Max in macOS using Geekbench

Again, my knowledge on how the CPU topology is handled in macOS is limited, and especially Intel's new Performance+Efficiency cores. - this is just a very (probably stupid) suggestion

If this isnt a stupid suggestion though, I'm open to providing my system as a testing platform. Intel Core i9-14900KF (8 Performance + 16 Efficiency (24c total), 32 threads) AMD Radeon RX 6900 XT (XTXH Variant) Full specifications available on GitHub

Also I looked up how macOS manages the performance and efficiency cores with the M series chips and found some interesting information.

https://mjtsai.com/blog/2022/04/25/how-macos-manages-m1-cpu-cores/

macOS doesn’t provide direct access to cores, core types, or clusters, at least not in public APIs. Instead, these are normally managed through Grand Central Dispatch using Quality of Service (QoS) settings, which macOS then uses to determine thread management policies.

macOS strategy is to load E cores heavily with system tasks, and spare P cores for user tasks. This ensures the user is unaware of and unaffected by heavy system workloads. It also minimises battery use in notebooks.

I would like to ask you a question. The CPU I am using is also 14900k. I am a front-end development programmer and I pay more attention to the retrieval and code compilation speed of browsers and webstorm. Not sure whether using this plug-in can improve the performance of the CPU (or the single-core/multi-core scores of cinebench R24), thereby improving my work efficiency
This is my current configuration, (without using this plugin)