Skip to content
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

Implement M3 (Max) in asitop #74

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Implement M3 (Max) in asitop #74

wants to merge 2 commits into from

Conversation

hughescr
Copy link

This patch does a couple things:

(1) Implements M3 Max support (at least for the 16 core CPU/40 core GPU version) 128GB version with 400MHz memory bandwidth) - the max power numbers are taken from my system driving CPU and GPU usage to absolute maximum and reading out from powermetrics.

(2) In order to calculate the average CPU usage across cores, I had to redo that whole section. On M3 Max, powermetrics always reports 100% for "E-Cluster online" and "P-Cluster online" for all clusters, regardless of how busy they are. So those basically can't be trusted/used. Instead, I just iterate through all the individual cores and average them. For the MHz, the clusters do report a frequency but it's not at all clear what the freq is when comparing it to the individual cores in that cluster. So instead of using those, and because there's multiple P-clusters anyway, I had to do an "average" - so what I decided to do was take each core's frequency, weighted by that core's activity %age - so the more active, the more that frequency contributes to the "average". This gives a sense, alongside the overall activity %age, of how hard the CPUs are actually working, kinda. It's not great, but it's better than nothing.

…- power levels measured on device using powermetrics and maxing out CPU/GPU usage)
… work on all processors.

Do not use the cluster info from powermetrics because it seems to just be wrong on later chips like M3.  Instead, calculate averages from the individual cores.
For the MHz, weight the MHz of each core by that core's activity level; I don't know if this is the right approach here - but this will give a sense of roughly the MHz of the "average" chip that's actually doing something, so idle cores at low MHz won't drag the number way down when a few cores are cranking at high MHz/100% utilization.
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

Successfully merging this pull request may close these issues.

None yet

1 participant