Today in Wayland compositor profiling! Turns out closing a shm pool file descriptor can result in a fat stall of up to like 6 ms with the kernel waiting on some spinlocks. Which is extra fun when you realize it covers the entire frame budget of your 165 Hz screen, and some clients are sometimes doing it every frame!
I'm trying a "dropping thread" workaround where the fd closing happens on a separate thread. Appears to work at the first glance.
new main loop stall dropped
and it is, uhhhhh, epoll_wait doing blocking disk decryption for solid 8 ms? is that a thing that it does?
seems to have happened once over a long period but still