# WindowServer GPU contention and display-sleep mitigation > 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. Parent: [Mac local LLMs: GPU stability and kernel panics](https://llms-explorer.com/tree/mac-local-llms-gpu-stability-and-kernel-panics/) · 1 facets · 16 facts · page: https://llms-explorer.com/tree/windowserver-gpu-contention-and-display-sleep-mi/ ## 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: `asserted` - 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: `asserted` - 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: `asserted` - 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: `asserted` - 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: `asserted` - 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: `asserted` - 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: `asserted` - Does a headless virtual display (no panel) avoid the interactivity kill and the M5 Max stall the way display sleep does? — source: `asserted` - Does macOS 27 change the interactivity check? No source found. — source: `asserted` - 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](https://github.com/ml-explore/mlx/issues/3267) - 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](https://raw.githubusercontent.com/Harperbot/metal-guard/main/CHANGELOG.md) - 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](https://github.com/jundot/omlx/issues/4224) - 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](https://astropad.com/blog/dummy-plug-headless-mac-mini/) - 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](https://github.com/jundot/omlx/issues/3706) - No source found tests the interactivity watchdog, `AGX_RELAX_CDM_CTXSTORE_TIMEOUT` or display sleep on macOS 27. — source: `asserted` - No source found whether a headless Mac's virtual display counts as an active display for the interactivity check. — source: `asserted`