WindowServer GPU contention and display-sleep mitigation
Parent: Mac local LLMs: GPU stability and kernel panics · Published reference · snapshot 2026-10-05
↓ Facts as markdownall context files
The contention measure that matters is WindowServer's share of GPU time while a long workload runs, not memory or heat; in the oMLX two-engine Hang class WindowServer held at most 2.8% of GPU time and the class is unrelated to this watchdog.
These notes link each claim to its source. A source may be a research report hosted on this site rather than the primary document. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Facts
- The contention measure that matters is WindowServer's share of GPU time while a long workload runs, not memory or heat; in the oMLX two-engine Hang class WindowServer held at most 2.8% of GPU time and the class is unrelated to this watchdog. [source]
- A headless Apple silicon Mac still runs WindowServer against a virtual display; this is why "no monitor" is not the same as "display off". [source]
- The display-sleep guidance in mlx 3267 (2026-04-27 comment) gives a concrete setting: System Settings, Lock Screen, "Turn display off when inactive: 1 minute". [source]
- 2026-06-27: `pmset displaysleepnow` (display asleep, system awake) shown on the M5 Max to clear the watchdog panic that `caffeinate -s` plus the env var did not. [source]
- On M1 and later Mac minis a virtual display is created automatically when no monitor is attached, at a default of 1920 by 1080 non-Retina; dummy HDMI plugs are an Intel-era habit. Whether that virtual display keeps the interactivity check armed is untested in any source found. [source]
- A second Metal process at a higher scheduling class (`Nice=-5`, `ProcessType=Interactive`) was proposed as a contention cause on macOS 27 and then refuted by measurement (priority parity changed nothing). Scheduling class is not the mechanism for GPU-queue contention. [source]
- None new. The existing split stands: the env var alone resolves the process kill for most reporters, but is insufficient on an M5 Max with a live display. [source]
- Does a headless virtual display (no panel) avoid the interactivity kill and the M5 Max stall the way display sleep does? [source]
- Does macOS 27 change the interactivity check? No source found. [source]
- The mlx 3267 mitigation list names the setting System Settings, Lock Screen, "Turn display off when inactive: 1 minute" as the way to make the display sleep so WindowServer yields the GPU. [source]
- MetalGuard records the display-contention kill as `WORKLOAD_ADVISORIES["lora_with_display_active"]`, reproducible 4 of 4 on macOS 26.2 and 26.3.1, with workaround display sleep plus `caffeinate -s`. [source]
- At every oMLX 4224 hang interval, WindowServer held at most 2.8% of GPU time and the terminal emulator at most 2.5%, against 94.7-98.8% for the inference process. [source]
- Apple silicon Mac minis (M1 and later) create a virtual display automatically when no monitor is attached, defaulting to 1920 by 1080 non-Retina. [source]
- The 3706 reporter removed `Nice=-5` and `ProcessType=Interactive` from a co-hosted Metal process and the macOS 27 Timeout faults did not change, so scheduling class was not the mechanism. [source]
- No source found tests the interactivity watchdog, `AGX_RELAX_CDM_CTXSTORE_TIMEOUT` or display sleep on macOS 27. [source]
- No source found whether a headless Mac's virtual display counts as an active display for the interactivity check. [source]
Children
- No children recorded.