"… Single-cluster, symmetric (SMP) systems can run with just the Clutch policy, but multi-cluster, asymmetric (AMP) systems must further enable the Edge policy extension to Clutch in order to manage scheduling across the multiple CPU clusters. …"
interesting. id love an eclecticlight breakdown of this. they're one of the few if only that write anything worth reading on apple hardware, i once found a QOS/scheduler insight through those guys when I couldn't get my c/cpp project pinned to the cores I wanted on m-series. https://eclecticlight.co/m1-macs/
It's used in iOS as well. iOS runs in some unexpected places, like for example Studio Display. Also, the Apple Lightning Digital AV Adapter runs Darwin (because RTKit didn't exist yet).
For Intel platforms, the Touch Bar is driven by the trusted coprocessor (T1/T2), but that itself runs bridgeOS which indeed is Darwin/watchOS-based. With Apple Silicon I don't know if bridgeOS is still used; the SEP runs an L4.
Well x86 at one point, arm both the 32 and 64 bit versions. I think they had RISCV support in their source tree at one point but not really at a commercial level. It does cover a lot different levels of hardware though
Does Apple use macOS in servers in its datacentres? Or are they all Linux?
Surely at a minimum they need macOS for CI.
Apple does have one advantage here-they can legally grant themselves permission to run macOS internally on non-Apple hardware, and I don’t believe doing so legally obliges them to extend the same allowance to their customers.
But that might give them a reason to keep x86_64 alive for internal use, since that platform (still) gives you more options for server-class hardware than ARM does
Well there were still the historical arm32 chips in their iOS devices, but until recently the watches were a cursed arm64_32 (or something like that) which is arm64 with 32 bit pointers iirc.
I'm sure there's vestiges of them somewhere, but the underlying support (the architecture specific parts of the mach portion of the kernel) is gone for those archs.
IIRC, Apple uses 'platform' to refer to an SoC integration. For example, M1, M2 and etc. are separate platforms. M5 in Vision Pro is a separate platform than M5 in MacBook Pro. I believe Apple's XNU does somewhat still support non-Apple Silicon as well though.
Audio actually runs on a dedicated realtime thread. This used to be scheduled differently, but nowadays it might be implemented by the FIXPRI bucket described in this document.
CoreAudio probably deserves most of the credit, there. Similar ASIO-style solutions like JACK, DirectSound and now Pipewire hit the sub-30ms mark without any big scheduler tweaks.
Darwin had bunch of schedulers except this one: dualq, multiq, etc
In fact here's the one used in Sonoma: sysctl kern.sched -> edge
which seems to be an extension over "clutch":
https://github.com/apple-oss-distributions/xnu/blob/main/osf...
"… Single-cluster, symmetric (SMP) systems can run with just the Clutch policy, but multi-cluster, asymmetric (AMP) systems must further enable the Edge policy extension to Clutch in order to manage scheduling across the multiple CPU clusters. …"
interesting. id love an eclecticlight breakdown of this. they're one of the few if only that write anything worth reading on apple hardware, i once found a QOS/scheduler insight through those guys when I couldn't get my c/cpp project pinned to the cores I wanted on m-series. https://eclecticlight.co/m1-macs/
He doesn’t read code. Convert it to some log messages and he might explore it.
> The XNU kernel runs on a variety of platforms
This is fascinating, would love to know where it’s used! (Besides macOS)
I believe it means Apple's other hardware platforms (phones, tablets, smart TVs, VR headsets, smartwatches)
All of Apple's platforms.
It's used in iOS as well. iOS runs in some unexpected places, like for example Studio Display. Also, the Apple Lightning Digital AV Adapter runs Darwin (because RTKit didn't exist yet).
And touchbars too, strangely enough.
For Intel platforms, the Touch Bar is driven by the trusted coprocessor (T1/T2), but that itself runs bridgeOS which indeed is Darwin/watchOS-based. With Apple Silicon I don't know if bridgeOS is still used; the SEP runs an L4.
Perhaps they mean ISAs
Well x86 at one point, arm both the 32 and 64 bit versions. I think they had RISCV support in their source tree at one point but not really at a commercial level. It does cover a lot different levels of hardware though
Does Apple use macOS in servers in its datacentres? Or are they all Linux?
Surely at a minimum they need macOS for CI.
Apple does have one advantage here-they can legally grant themselves permission to run macOS internally on non-Apple hardware, and I don’t believe doing so legally obliges them to extend the same allowance to their customers.
But that might give them a reason to keep x86_64 alive for internal use, since that platform (still) gives you more options for server-class hardware than ARM does
Which Apple products run arm32 XNU? Their first Apple Silicon CPUs were already arm64.
Well there were still the historical arm32 chips in their iOS devices, but until recently the watches were a cursed arm64_32 (or something like that) which is arm64 with 32 bit pointers iirc.
PPC32/64 of course, and for a long time Darwin still contained remnants of its predecessor's support for SPARC, PA-RISC, and m68k.
Is mc68k or PPC still in there anywhere?
I'm sure there's vestiges of them somewhere, but the underlying support (the architecture specific parts of the mach portion of the kernel) is gone for those archs.
IIRC, Apple uses 'platform' to refer to an SoC integration. For example, M1, M2 and etc. are separate platforms. M5 in Vision Pro is a separate platform than M5 in MacBook Pro. I believe Apple's XNU does somewhat still support non-Apple Silicon as well though.
Yeah they're was that whole x86 thing thru did for quite a while.
Does this contribute to macOS's suitability for DAW applications or is that more the baked in low-latency audio drivers?
Audio actually runs on a dedicated realtime thread. This used to be scheduled differently, but nowadays it might be implemented by the FIXPRI bucket described in this document.
CoreAudio probably deserves most of the credit, there. Similar ASIO-style solutions like JACK, DirectSound and now Pipewire hit the sub-30ms mark without any big scheduler tweaks.
IOKit was designed to support CoreAudio from the start, cc gvdl.