From time to time, often after I’ve restored from sleep or finished playing a Steam game, one of my CPU cores is pinned at 100% with no indication of what might be doing it. Running htop, btop, or GNOME system monitor all show the same thing: CPU0 at 100% while the rest are doing near-nothing, and no process in particular seems to be using those resources.
If I restart, it’s back to normal, and sometimes I can play a game in Steam or let the computer go to sleep and it doesn’t do this, but it happens often enough that’s annoying/confusing so I’d like to know if there’s a way to either (a) diagnose which processes are using which CPU cores, or (b) somehow “reset” the checking of these values to make sure that something’s not just being misreported.
This is a desktop system running Arch & GNOME.
It’s probably Shader compilation. Funny enough the top result of my websearch is my own post/thread in Reddit 4 years ago. I had this exact same question on my old computer: https://www.reddit.com/r/linux_gaming/comments/kyf1wf/why_is_steam_using_one_core_always_but_doing/ Shader compilation is done from time to time in the background while Steam runs. This prepares games to run better.
Look if there is a process called
fosselize
. That was the process name back then doing the Shader compilation.I’d never even heard of shader compilation. Apparently for the Steam Deck, Valve provides pre-compiled shaders for some games. What Is Shader Compilation and Why Does It Make PC Games Stutter?
Yes. That’s the benefit of having a single hardware to target. Same goes for consoles. They obviously know the hardware (like in Steam Deck’s case) and can precompile and ship it. There was plans (or just talks? not sure if this was ever realized) that users can download precompiled Shaders from other users, if its the exact same hardware.
deleted by creator
The problem with fosselize is that it’s currently bugged, and happens to precompile way more things than are needed, such as all workshop content that you might not have installed which takes a really long time + bloats up the shader cache in size. On anything that’s not low-end, it’s pretty much a waste of time since shader compilation is easily done on runtime.
Some issues on the things I’ve mentioned that Valve hasn’t seem to have responded yet: bloat, time