Apple XNU: Clutch Scheduler

(github.com)

79 points | by tosh 4 hours ago

3 comments

  • trueno
    3 hours ago
    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/
  • cadamsdotcom
    2 hours ago
    > The XNU kernel runs on a variety of platforms

    This is fascinating, would love to know where it’s used! (Besides macOS)

    • csb6
      2 hours ago
      I believe it means Apple's other hardware platforms (phones, tablets, smart TVs, VR headsets, smartwatches)
    • LoganDark
      42 minutes ago
      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).
    • electronsoup
      2 hours ago
      Perhaps they mean ISAs
      • xphos
        1 hour ago
        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
        • kjs3
          11 minutes ago
          Is mc68k or PPC still in there anywhere?
        • wiml
          38 minutes ago
          PPC32/64 of course, and for a long time Darwin still contained remnants of its predecessor's support for SPARC, PA-RISC, and m68k.
      • LoganDark
        1 hour ago
        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.
        • fragmede
          50 minutes ago
          Yeah they're was that whole x86 thing thru did for quite a while.
  • almoni
    2 hours ago
    Does this contribute to macOS's suitability for DAW applications or is that more the baked in low-latency audio drivers?
    • dcrazy
      1 hour ago
      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.
    • bigyabai
      2 hours ago
      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.