Main thread stalls in xe_exec_ioctl freeze cursor/input under memory pressure; gainRealTime() silently never applies under uwsm

[dragosol]

Hyprland 0.56.2 (Arch / Omarchy 4.0.4, launched by uwsm as wayland-wm@hyprland.desktop.service), aquamarine 0.15.0, kernel 7.2.5, Intel Core Ultra 7 256V / Arc 140V (xe), 16 GB RAM.

Two related things make Hyprland the first casualty of memory pressure on small machines. With a background job running, the cursor and input freeze for 0.3–1.5 s at a time.

1. gainRealTime() silently never applies under a systemd/uwsm session

ps -o cls,rtprio,ni -p $(pidof Hyprland) shows TS - 0: the main thread is plain SCHED_OTHER. The unit has LimitRTPRIO=0 and the binary has no CAP_SYS_NICE, which is how every uwsm-launched session ships by default. hyprland.log contains none of the gainRealTime messages (Failed to change process scheduling strategy etc.), so nothing tells the user that Hyprland is running without realtime.

Suggestions:

• Fall back to RealtimeKit (org.freedesktop.RealtimeKit1.MakeThreadRealtime) when sched_setscheduler isn't permitted. Mutter does this for its KMS thread (KWin gets CAP_SYS_NICE from its package instead). rtkit is on basically every desktop already, because PipeWire uses it.
• Log one clear line at startup saying which scheduling class the main thread actually got.

2. The main thread blocks in xe_exec_ioctl, so input and cursor freeze with it

I sampled the kernel stack of Hyprland's main thread whenever its IPC ping went over 50 ms. Under memory pressure, 20 of 27 captures were:

drm_exec_lock_obj+0xd9/0x220 [drm_exec]
drm_gpuvm_exec_lock+0xda/0x100 [drm_gpuvm]
xe_validation_exec_lock+0x5e/0xb0 [xe]
xe_exec_ioctl+0x9f2/0xe60 [xe]

(state S, Hyprland at ~0–20% CPU). Hyprland submits rendering on the main thread, and the driver blocks that submit while TTM evicts buffers to make room. The worst single stall was 1529 ms. Cursor movement, input dispatch and IPC all sit on the same thread, so they stop with it. Realtime scheduling wouldn't help here, because the thread is sleeping on a lock, not waiting for a CPU.

This is mostly a driver/memory issue, but the compositor architecture decides how bad it feels. Mutter moved KMS commits (including the cursor plane) onto a dedicated thread for this reason. Has Hyprland considered moving cursor-plane updates and input handling off the render thread, or at least keeping the hardware cursor moving while a render submit is blocked?

Happy to provide the sampler (Python, reads /proc/<pid>/task/<tid>/stack while the main thread is blocked) or full logs.

[github-actions[bot]]

This discussion has been automatically closed.
Discussion format is NOT optional!

[github-actions[bot]]

⚠️ Strike 1/3 issued to @dragosol by system.