M1 vs M1 Max - macOs Archive Utility

Nycturne said:
To speak to your comment about priority rebalancing, here's something to consider: the scheduler priority isn't used when recommending P or E cores for a thread, only the base priority. So this sort of rebalancing wouldn't have the effect of changing the recommendation.

I've mostly been reading through the code since I'm curious. There's certainly pieces that I haven't gleaned yet, but so far the key things driving things that I see in the code match up with the sort of analysis that eclecticlight.co has been doing on the scheduler's behavior. About the only thing I haven't seen in action yet that I've read in the code are around trying to keep threads within the same group on the same CPU cluster. Possibly because it's not a common case where you've got threads in a group with different base priorities. However, it does also apply for keeping those threads on the same P cores rather than having them spread across the two different CPU clusters on the M1 Pro/Max.
Click to expand...
Wasn't aware it kept both. Thought the priority rebalancing changed the base priority in-place. Makes sense.

Any tips for reading the source? Did you just start in osfmk/sched.h and move on from there? Or the affinity.c/h files? They seem to be pretty closely tied to thread-core placement.
It also looks like the XNU documentation section on adding a custom sys call has been removed from the GitHub page though the heading is still there which is pretty odd
 
casperes1996 said:
Wasn't aware it kept both. Thought the priority rebalancing changed the base priority in-place. Makes sense.

Any tips for reading the source? Did you just start in osfmk/sched.h and move on from there? Or the affinity.c/h files? They seem to be pretty closely tied to thread-core placement.
It also looks like the XNU documentation section on adding a custom sys call has been removed from the GitHub page though the heading is still there which is pretty odd
Click to expand...

I didn’t even think to see if Apple posted the source of XNU on GitHub. I mostly loaded up a dump of the source from 11.5 in VS Code so it was properly searchable. But the key bits for scheduling on AMP systems like M1 lives in sched_amp_common.h/.c and sched_amp.c, unsurprisingly. If you are curious about the P vs E aspects of scheduling, that’s where I’d start. I also just noticed there’s a pretty decent Markdown file included in sched_clutch.md which does a pretty good job giving a high level overview of the current scheduler behavior, specifically how QoS, thread groups and threads create a hierarchy for the scheduler where different approaches are applied for scheduling. However, this appears to be orthogonal for how scheduling happens for processor clusters (psets), where threads and thread groups get assigned or recommended a cluster, and then the scheduler for a specific core goes from there deciding which bucket, group and ultimately thread it executes next.

Thread affinities are disabled outside of macOS, so they aren’t really relevant for AMP scheduling.

Honestly, it helps if there’s a specific question I want to answer. It’s a lot easier to pull things apart when I can focus on something specific by finding the appropriate thread. For example, finding the AMP scheduling code without knowing that Apple used the “AMP” term was driven by me searching for references to E cores.
 
Nycturne said:
I didn’t even think to see if Apple posted the source of XNU on GitHub. I mostly loaded up a dump of the source from 11.5 in VS Code so it was properly searchable. But the key bits for scheduling on AMP systems like M1 lives in sched_amp_common.h/.c and sched_amp.c, unsurprisingly. If you are curious about the P vs E aspects of scheduling, that’s where I’d start. I also just noticed there’s a pretty decent Markdown file included in sched_clutch.md which does a pretty good job giving a high level overview of the current scheduler behavior, specifically how QoS, thread groups and threads create a hierarchy for the scheduler where different approaches are applied for scheduling. However, this appears to be orthogonal for how scheduling happens for processor clusters (psets), where threads and thread groups get assigned or recommended a cluster, and then the scheduler for a specific core goes from there deciding which bucket, group and ultimately thread it executes next.

Thread affinities are disabled outside of macOS, so they aren’t really relevant for AMP scheduling.

Honestly, it helps if there’s a specific question I want to answer. It’s a lot easier to pull things apart when I can focus on something specific by finding the appropriate thread. For example, finding the AMP scheduling code without knowing that Apple used the “AMP” term was driven by me searching for references to E cores.
Click to expand...
You know how when you see an abbreviation you don't recognise, you either guess at its meaning or it kinda just disappears to your eye? When looking over the source files I glazed over all the things marked AMP not recognising the abbreviation. I googled and it's apparently Asymmetric Multi-Processor so that makes a lot of sense. Hadn't noticed the markdown file either. Very helpful, thanks :)
 
That Markdown file was gold. There's a lot of detail I still haven't worked out but it helped a darn lot with the high level overview I was after
 
Back
Top