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. Some citations identify archived research reports that are no longer hosted on this site. 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.