3 ms·

You do realize it's the thing compositing your desktop, right? it's not 1995

londons_explore 3y ago
For which, no CPU time is needed - all it's doing is pointing the GPU towards the right buffers to render in the right places.
- pengaru 3y ago
  It's a long-running process that's waking up constantly for IPC+compositing duties alone. If you're still on X I'd expect more of the compositing cost reflected in the Xorg process than gnome-shell. But on a "modern" Wayland-based gnome session, the gnome-shell process encompasses what used to occur in Xorg. So all that time is now attributed to gnome-shell. It's not like you just arrange the GPU with some buffers and never wake up to send it commands on what to draw when. The compositor is a rather busy process, esp. if you have many clients/windows active. This stuff was easier to reason about in the Xorg days with WM "policy" running in a clearly separate process from the X "mechanism" side. Wayland tends to conflate everything, unless the compositor developers choose to use separate well-labeled threads for things like input/compositing/policy... I don't personally use gnome so it's inconvenient for me to check despite mild curiosity. It may be interesting to look at a threaded view of `top` if you're on Wayland, and see if gnome-shell has clearly separated threads. Interestingly, modern Xorg uses separate threads now, from this machine: 524 anon 20 0 637516 92996 53592 S 5.3 0.6 82:54.35 Xorg 525 anon 39 19 637516 92996 53592 S 0.0 0.6 0:00.00 Xorg:disk$0 526 anon 20 0 637516 92996 53592 S 1.0 0.6 36:32.18 Xorg:gdrv0 527 anon 39 19 637516 92996 53592 S 0.0 0.6 0:00.00 Xorg:disk$0 529 anon 20 0 637516 92996 53592 S 1.0 0.6 1:10.52 InputThread So gdrv0 alone has consumed 36.5 hours during my ~1.5 day uptime. If this were a Wayland situation, that time would be reflected in my compositor process instead. ~83 hours for the main Xorg thread, which I presume is largely IPC but X also does heaps of crap from its huge protocol on-CPU so I think it's best to just ignore that.
  - londons_explore 3y ago
    I debugged it, and found: https://news.ycombinator.com/item?id=36608714 https://news.ycombinator.com/item?id=36608714

For which, no CPU time is needed - all it's doing is pointing the GPU towards the right buffers to render in the right places.

pengaru 3y ago
It's a long-running process that's waking up constantly for IPC+compositing duties alone. If you're still on X I'd expect more of the compositing cost reflected in the Xorg process than gnome-shell. But on a "modern" Wayland-based gnome session, the gnome-shell process encompasses what used to occur in Xorg. So all that time is now attributed to gnome-shell. It's not like you just arrange the GPU with some buffers and never wake up to send it commands on what to draw when. The compositor is a rather busy process, esp. if you have many clients/windows active. This stuff was easier to reason about in the Xorg days with WM "policy" running in a clearly separate process from the X "mechanism" side. Wayland tends to conflate everything, unless the compositor developers choose to use separate well-labeled threads for things like input/compositing/policy... I don't personally use gnome so it's inconvenient for me to check despite mild curiosity. It may be interesting to look at a threaded view of `top` if you're on Wayland, and see if gnome-shell has clearly separated threads. Interestingly, modern Xorg uses separate threads now, from this machine: 524 anon 20 0 637516 92996 53592 S 5.3 0.6 82:54.35 Xorg 525 anon 39 19 637516 92996 53592 S 0.0 0.6 0:00.00 Xorg:disk$0 526 anon 20 0 637516 92996 53592 S 1.0 0.6 36:32.18 Xorg:gdrv0 527 anon 39 19 637516 92996 53592 S 0.0 0.6 0:00.00 Xorg:disk$0 529 anon 20 0 637516 92996 53592 S 1.0 0.6 1:10.52 InputThread So gdrv0 alone has consumed 36.5 hours during my ~1.5 day uptime. If this were a Wayland situation, that time would be reflected in my compositor process instead. ~83 hours for the main Xorg thread, which I presume is largely IPC but X also does heaps of crap from its huge protocol on-CPU so I think it's best to just ignore that.
- londons_explore 3y ago
  I debugged it, and found: https://news.ycombinator.com/item?id=36608714 https://news.ycombinator.com/item?id=36608714