[Bug 45121] Steam uses high CPU while idle

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=45121

--- Comment #14 from Etienne Dechamps <etienne at edechamps.fr> ---
Out of curiosity I ran Steam under an API tracer on a Windows 10 machine and,
to my surprise, I saw the exact same thing as I saw in the wine relay logs.
It's doing the same busy loop even under native Windows. So the busy loop
itself is *not* the consequence of a Wine bug.

This is starting to look like poor design on Steam's side. That being said, on
native Windows the CPU usage from that thread is much lower. What I suspect is
happening is: the calls in question might be cheaper on Windows than on Wine;
and/or Windows might make the thread sleep for longer during the Sleep(0) calls
that Steam makes on each iteration.

I used the Windows Performance Toolkit on the Windows machine to investigate
further. On native Windows, the thread in question iterates at roughly the same
rate (~1000 times per second) than on my Wine setup, but each iteration is very
quick - about 42 µs on average. This leads to about 4% utilization of a single
CPU. The Windows Task Manager will show an even smaller number because,
contrary to "top", it divides CPU usage by the number of CPUs, which might
contribute to the perception that the CPU usage is lower than on Wine.

I haven't checked how long the iteration takes on my Wine setup, but judging
from the CPU usage numbers I'd estimate it's at least 4 times slower. The Win32
functions being called have likely been optimized to death on native Windows,
but on Wine they have to go through several round trips to the wineserver,
which involves context switches etc.

As for fixing this problem, I can see a few possible avenues at this point:
- Ask Valve to fix their poorly designed busy loop. (Good luck.)
- Optimize the Wine implementation of the offending Win32 calls. (I don't know,
caching maybe?)
- Implement some kind of clever Steam-specific workaround where Wine detects
that it's being called from that loop and deliberately throttles it (e.g. by
changing the Sleep(0) call to Sleep(10ms), which would reduce CPU usage by a
factor of ~10).

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.