cosmic-comp enters unthrottled render loop after lock screen resume

[neilfrndes]

Environment:

• Pop!_OS 24.04 LTS (COSMIC desktop)
• cosmic-comp version: 0.1177030434724.04~0e97ddb
• AMD Radeon 2100 GPU
• Single LG HDR WQHD 3840x1600 ultrawide on DP-3 (two other DP connectors present but disconnected)

Related issues:

• High GPU utilization (40%) at idle with mixed refresh rate multi-monitor setup (NVIDIA) #2153 — same ~40% idle utilization and tight epoll loop, triggered by mixed refresh rate multi-monitor on NVIDIA
• [Bug] high-cpu usage leads to mouse stuttering #2062 — gradual CPU increase over time leading to mouse stuttering, linked to fix: avoid timer churn in idle_notify on every input event Smithay/smithay#1927
• "Solved" an interesting performances issue with cosmic-comp and cosmic-panel and tray icons #1967 — CPU climbs to 25% over days, linked to tray icon rendering

My issue appears to share the same root cause as #2153 (unthrottled compositor render loop) but with a different trigger and hardware.

Bug summary:
After resuming from the COSMIC lock screen, cosmic-comp sometimes starts consuming ~40% CPU indefinitely (for hours/days). The system becomes sluggish (obvious mouse/keyboard lag) with high I/O wait times (~22%). The only fix is restarting the compositor, which destroys all open windows and workspaces.

This does not happen every time — it tends to occur after long sessions (days of uptime) followed by a lock screen resume.

What I found:

1. After resume, the display had dropped from the preferred 59.994 Hz to 49.985 Hz (confirmed via cosmic-randr list). Manually switching back to 59.994 Hz did not fix the CPU usage.

2. strace on the compositor shows timerfd intervals in the microsecond range instead of the expected ~16.6ms for 60Hz vsync. The compositor is scheduling frames hundreds of times per second:

timerfd_settime(6, 0, {it_value={tv_sec=0, tv_nsec=9242}}, ...)
timerfd_settime(6, 0, {it_value={tv_sec=0, tv_nsec=16360}}, ...)
timerfd_settime(6, 0, {it_value={tv_sec=0, tv_nsec=950544}}, ...)
timerfd_settime(6, 0, {it_value={tv_sec=0, tv_nsec=1575508}}, ...)

3. A 2-second strace captured 8,772 syscalls (~4,400/sec) in a tight epoll + DRM_IOCTL_SYNCOBJ loop — submitting and completing GPU frames as fast as possible with no vsync gate. This matches the pattern reported in High GPU utilization (40%) at idle with mixed refresh rate multi-monitor setup (NVIDIA) #2153.

4. top -H shows the main cosmic-comp thread at ~39% CPU (state R), and the surface-DP-3 thread at ~4% CPU. Total CPU time accumulated was 253+ hours.

5. Kernel stack shows ep_poll but the process is in R state — it wakes from epoll almost immediately each cycle.

6. No GPU errors in dmesg. GPU driver and hardware appear healthy.

7. Manually switching the refresh rate back to 59.994 Hz via cosmic-randr did not resolve the CPU usage — the render loop persists even after the correct mode is restored.

Expected behavior:
After lock screen resume, the compositor should re-establish vsync timing and idle at <2% CPU when nothing is animating.

Actual behavior:
The compositor loses vsync synchronization and enters an unthrottled render loop, burning ~40% CPU indefinitely until the compositor process is restarted.

[Lcstyle]

I've been investigating suspend/resume and DPMS behavior on a 4-output NVIDIA setup (cosmic-comp #2096, #2078) and I think there's a connection worth noting.

The symptom here — timerfd_settime firing at microsecond intervals in a tight epoll + DRM_IOCTL_SYNCOBJ loop — looks like the compositor's vblank synchronization isn't being re-established after the lock screen resume path. The reporter's observation that the output dropped from 59.994 Hz to 49.985 Hz on resume is interesting — it suggests an output reconfiguration happened, and the frame scheduling timer never re-locked to the new (or restored) vblank cadence.

A few data points from my own debugging that might be relevant:

• After S3 resume and DPMS-on transitions, I've seen surfaces that never receive frame callbacks again (stuck in a "waiting for callback" state). That's a different visible symptom (grey lock screen rather than high CPU), but the trigger is the same class of problem — power state transitions leaving compositor internal state partially stale.
• In my testing, I found that the compositor needs to explicitly re-deliver frame callbacks after S3 resume and DPMS-on to unblock clients. But there are other "output became active" paths that likely need the same treatment — hotplug, mode switch, VT switch, DRM device reset. The reporter's mode change on resume (59.994 → 49.985 Hz) suggests this hit one of those adjacent paths where state recovery isn't happening.
• This is AMD Radeon, and High GPU utilization (40%) at idle with mixed refresh rate multi-monitor setup (NVIDIA) #2153 shows the same tight timer pattern on NVIDIA with mixed refresh rates. That points to compositor frame scheduling logic rather than anything driver-specific.
• Manually restoring the correct refresh rate via cosmic-randr didn't fix it — which suggests the stale state is in the timer/scheduling machinery, not the output mode itself.

#2153 could be a related entry point — the mixed refresh rate trigger might be easier to reproduce than the intermittent resume trigger.

[neilfrndes]

Attempted non-destructive workarounds (none successful):

1. kill -HUP on cosmic-comp → restarts compositor, destroys session
2. kill -9 on surface-DP-3 thread → crashes compositor, destroys session
3. VT switch (chvt 2 && sleep 2 && chvt 1) → session survives, render loop persists
4. Mode switch via cosmic-randr → session survives, render loop persists
5. Refresh rate change → no effect
6. cosmic-randr disable DP-3 / enable DP-3 → disable silently ignored, enable returns "configuration failed"

[neilfrndes]

There must be some connection between the Cosmic Files process and the bug described above. Terminating the cosmic-files process fixes the high CPU usage immediately.

[SuperJMN]

Additional data point for the post-resume / unthrottled-render-loop class of issue.

I have a Pop!_OS 24.04 NVIDIA desktop where the GUI starts out relatively smoother after boot, then becomes visibly janky after time/idle. In the latest reproduction I was able to tie the degradation to automatic S3 suspend/resume.

Environment:

• OS: Pop!_OS 24.04 LTS
• Session: COSMIC / Wayland
• Kernel: 6.18.7-76061807-generic
• CPU: Intel Core i7-7700
• GPU: NVIDIA GeForce GTX 1650 / TU117
• NVIDIA driver: 595.58.03
• cosmic-comp: 0.1~1778187638~24.04~b955789
• Non-hybrid desktop setup

Display setup:

• DP-1: 1920x1200 @ 59.950 Hz, scale 100%, Xwayland primary
• DVI-D-1: 1920x1080 @ 60.000 Hz, scale 100%
• HDMI-A-1: Huion Kamvas Pro 13, 1920x1080 @ 60.000 Hz, scale 150%

Trigger/timeline:

19:52:00 systemd-logind[913]: The system will suspend now!
19:52:01 kernel: PM: suspend entry (deep)
19:52:01 cosmic-comp[2391]: Failed to submit rendering: ... Atomic Test failed for new properties on crtc (crtc::Handle(62))
19:52:01 cosmic-comp[2391]: Failed to submit rendering: ... Atomic Test failed for new properties on crtc (crtc::Handle(81))
20:25:42 kernel: PM: suspend exit
20:25:42 kernel: NVRM: Xid (PCI:0000:06:00): 69, pid=4125, name=DotnetFleet.Des, Class Error ...

After resume, the desktop was not smooth and cosmic-comp remained expensive:

$ ps -C cosmic-comp -o pid,etimes,pcpu,pmem,rss,vsz,stat,cmd
PID   ELAPSED %CPU %MEM    RSS     VSZ STAT CMD
2391     9702 26.6  2.5 412856 1981600 S<l+ cosmic-comp

A short 5-second CPU delta sample showed the compositor even higher:

45.55% pid=2391 comm=cosmic-comp
19.66% pid=5918 comm=cosmic-term
14.85% pid=94067 comm=cosmic-term
 5.42% pid=2459 comm=cosmic-panel

nvidia-smi pmon -c 6 also showed recurring compositor GPU work after resume, with cosmic-comp reaching roughly 15-37% SM and 12-29% memory in the samples where it was active. System memory pressure was not the explanation (free -h showed ~8.3 GiB available), but IO pressure was high after resume:

/proc/pressure/io:
some avg10=43.66 avg60=42.75 avg300=48.70
full avg10=35.13 avg60=34.36 avg300=41.12

I did not capture strace in this run, so I cannot confirm the timerfd/DRM_IOCTL_SYNCOBJ loop directly. But the visible symptom and measurements match the same class: after lock/suspend/resume, the compositor remains in a high-work state until the session is restarted or otherwise reset.

[mkanat]

For what it's worth, I triggered this today with a single display on my AMD Granite Ridge iGPU, Fedora 44 COSMIC Spin.

Asked Claude to get me some debug info in case it helps with fixing the bug. I see the same strace pattern as above.

I've attached a very large bundle summarized with a README. I caught this all at a time when I wasn't moving my mouse or otherwise interacting with the machine at all.

Claude's summary, although there's a LOT more data in the attached zip.

perf record -g --call-graph dwarf for 30 s (1358 samples, fully symbolized) shows ~94 % of cycles in wayland-rs server-side surface lookups:

Self %	Symbol
24.17	wayland_backend::rs::server_impl::handle::InnerHandle::object_info
20.47	ErasedState<cosmic_comp::state::State>::object_info
14.21	WlSurface::from_id
10.83	InnerHandle::get_object_data_any
9.66	core::ptr::drop_in_place::<WlSurface>
9.26	Weak<WlSurface>::upgrade
5.84	ErasedState::get_object_data_any

perf annotate localizes 99 % of object_info to the cmpxchg / xchg of Mutex<dyn ErasedState>::lock/unlock — the loop is hammering one global state mutex on every lookup. Syscall counts agree: strace -c shows 4,556/sec total with futex at 500/sec, matching the contention.

Bundle attached: perf data + report + annotate, strace, all-thread gdb backtraces, journals, env.

20260516T144113Z.zip

[gmarkley-VI]

Same unthrottled-loop signature, but triggered at random (not only after lock/suspend resume) — with measurements isolating it to a CPU-side loop, GPU idle

I'm hitting what looks like this exact bug on Intel (i915), but my trigger appears random during normal use rather than specifically after
lock-screen/suspend resume. I caught it live and instrumented it; sharing data in case it helps separate this from the GPU-hang reports.

Environment

• Pop!_OS 24.04 LTS, Wayland
• cosmic-comp 0.1178046696924.04~2f7c34f (reports 1.0.0), upstream master build dated 2026-06-03
• Kernel 7.0.9-76070009-generic (System76)
• CPU/GPU: Intel Core Ultra 5 125U, Meteor Lake-P iGPU (i915, multi-GT GT0+GT1)
• Mesa 25.2.8

Symptoms

• Random onset; cosmic-comp pegs 100%+ CPU indefinitely, whole system lags, only a compositor/session restart recovers (loses all windows). Intermittent —
  sometimes runs fine for hours.

Measurements during a live spike (sampled from /proc):

• Instantaneous CPU ≈112% of a core, split user≈13 / kernel≈101 — i.e. ~88% of the time is in kernel space (syscall/ioctl storm), almost none in userspace.
• GPU render engine only ~17–24% busy (drm-engine-render delta from /proc//fdinfo/*). The GPU is essentially idle — this is not a heavy-rendering/damage
  loop.
• No i915/drm/GuC/GSC errors in the kernel log during the stall — so it is not a GPU hang/reset cycle.
• Main thread oscillates between R and D; nonvoluntary context switches ~291/s (scheduler-preempted = CPU-bound in kernel); system load climbs to ~25 on 14
  cores.
• perf record --call-graph dwarf -p captured zero useful userspace samples during the spike (time is in-kernel; perf_event_paranoid=2 blocked kernel
  sampling).

This matches the issue's described "tight epoll + DRM_IOCTL_SYNCOBJ loop / lost vsync gating" mechanism: the compositor burns kernel CPU
submitting/synchronizing frames while the GPU does little actual work. The notable addition here is that it occurs without any resume event in my case, so
the loop may have triggers beyond lock/suspend resume.

Recovery / workaround

• Restart the compositor (session restart).
• Downgrading cosmic-comp to 0.1177989301924.04~22fe419 (the build immediately prior to the 2026-06-03 update) is stable — that version ran 2.5 days
  without a single spike on identical hardware/kernel.

How to reproduce the measurement (for anyone confirming GPU-idle vs GPU-hang):
P=$(pgrep -x cosmic-comp|head -1)

instantaneous user/kernel CPU split over 1s:

read u1 s1 < <(awk '{print $14,$15}' /proc/$P/stat); sleep 1; read u2 s2 < <(awk '{print $14,$15}' /proc/$P/stat)
echo "user +$((u2-u1)) kernel +$((s2-s1))"

GPU render-engine busy % over 2s:

a=$(grep -h ^drm-engine-render /proc/$P/fdinfo/|head -1|grep -o '[0-9]'); sleep 2
b=$(grep -h ^drm-engine-render /proc/$P/fdinfo/|head -1|grep -o '[0-9]'); echo "render busy $(((b-a)/20000000))%"

[infowolfe]

I had grok debug/RCA and do a write-up on this. I'm getting bit hard by it since I'm using cosmic at work, so every time I have to leave my desk my machine gets progressively laggier and laggier.

Executive Summary: cosmic-comp unthrottled render loop (GitHub #2169 / related #2153, #2275)

Problem Space

• COSMIC Wayland compositor (cosmic-comp 1.0.15~2f7c34f2) on Pop!_OS/Ubuntu 26.04, AMD Strix Halo (Radeon 8060S), dual 4K DP outputs.
• Symptoms: 30-50% CPU in cosmic-comp (main + surface-DP-* threads), laggy input, ~5-6k minor faults/sec, extreme shm/dmabuf churn (672 FDs, 326 dmabufs, 73 memfds, dedicated "Shm dropping th" kernel evicts).
• Trigger: lock screen resume (confirmed by user; also multi-monitor mode changes, long uptime). Debug (strace/bpftrace/perf/gdb): timerfd_settime at 600-900+/sec (vs. ~120 expected), tight epoll + DRM ioctls (SYNCOBJ_CREATE/DESTROY, MODE_ATOMIC/PROPBLOB, AMDGPU_CS), surface threads memcpy + commits, no vsync gate. Matches reporter data exactly (microsecond timers, surface-DP threads ~4-39% CPU, ~4k syscalls/sec in epoll+DRM loop).
• wp_presentation advertised but ineffective; full normal client surfaces still composited.

The Bug
Compositor loses vblank/presentation sync after lock/resume (or mode/power transition). Per-output KMS surface threads fall into a self-reinforcing estimated-vblank loop that submits frames + buffers at max rate instead of idling at refresh.

Root Cause (Code – ~/cosmic-comp)

• src/backend/kms/surface/mod.rs:261: one surface-XXX thread per output (matches DP-9/DP-11).
• QueueState machine + queue_redraw (941) / queue_estimated_vblank (1410): computes timer via timings.next_presentation_time / next_render_time; ZERO → Timer::immediate().
• timings.rs:103,282,366: set_refresh_interval (called on mode changes) clears previous_frames; next_*_time returns ZERO with no last presentation_presented. queue_estimated_vblank adds refresh only if exactly zero, then chains.
• session_lock.rs:41,50 + state.rs:1296: lock/unlock calls schedule_render on all outputs and sends frames for lock surfaces (unthrottled), but redraw/output_elements still composites full normal scene (no culling of "invisible" clients).
• Real vblanks (device.rs:747) and presentation feedback are the only things that repopulate history; resume/power transitions + lock scheduling break the anchor before/while estimated path runs.

Proposed Fixes (minimal, targeted)

1. Timings: seed synthetic previous_frames entry on set_refresh_interval / init; fall back to refresh_interval (or /2 + margin) instead of ZERO.
2. Estimated path (queue_estimated_vblank / on_estimated_vblank): clamp duration to min (refresh/2 or 8 ms), track last fire, skip/extend if too soon. Only queue_redraw on force/animations when locked.
3. Lock-aware render: in redraw + queue_redraw, if shell.session_lock.is_some(), composite only lock surfaces + cursors; suppress normal workspaces/layers (fixes cosmic-comp composites invisible client surfaces while session is locked, causing high CPU and input corruption #2275 side).
4. Recovery: on output power resume / post-lock / mode change, reset timings (seed or force real vblank before estimated) and call schedule_render with force flag.
5. Safety: consecutive-immediate counter; force min delay + trace after threshold.

These preserve the existing low-latency estimated logic (avg_submittime + margins) while eliminating the history-loss + lock-transition failure modes. All symptoms (timer storm, buffer churn, surface-thread CPU, invisible-surface compositing) collapse once the loop rate is throttled at the source.

Artifacts (perf.data, strace logs, ptrace_scope=0) remain available at /tmp. Patches or further code reads available on request.

[exodious]

This is also happening to me. It happens whenever the screen is locked. I don't know how to measure the GPU usage in this state, but if I leave the system monitor app up, lock the screen, wait for the fans to kick on (happens within moments), then unlock I can see spikes up to ~40% usage.

My system:

• Pop!_OS 24.04
• cosmic-comp 0.1178466532724.04~4d370cd
• System76 Lemur Pro 10
• Intel i5-1135G7 (integrated Iris Xe GPU)
• This occurs regardless of whether am using the built in display or an external display