[Bug 6936] eMule uses 40% CPU when idle permanently, independent of CPU speed

[wine-bugs at winehq.org]

http://bugs.winehq.org/show_bug.cgi?id=6936





--- Comment #25 from Anastasius Focht <focht at gmx.net>  2007-11-27 18:56:05 ---
Hello,

--- quote ---
Thank you Anastasius for your analysis, it may well be the first step in the
right direction, since this bug has been first reported almost a year ago.
--- quote ---

Well, I noticed this bug id today, while looking for interesting bug reports
... consider yourself lucky ;-)

--- quote ---
Is this behaviour fixable with a patch or is it inherent fault of wine and and
emule that cant be sorted?
--- quote ---

Well on both systems - windows and wine/linux - the same amount of idle
messages is generated (actually WM_KICKIDLE and WM_TIMER).

To compare application performance between wine/linux and Windows, I use
certain performance counters in Windows which reflect some operating systems
aspects better than simple "CPU load".
Namely "context switches", "context switch delta", "page faults" and "page
fault deltas".

Technically Windows "cheats" when it comes to CPU load (task manager, process
viewer and the like) ;-)
Many threads run for such a short amount of time that they are rarely the
currently running thread when the interval clock timer interrupt occurs and
hence are not charged for their CPU time (resulting in zero CPU load).

By tracking certain performance counter values one can get a good impression
what is going on under the hood ...

On Windows XP, the context switch delta ("thread activity") for emule is about
700-1200 per second with plain gui (no connections).
A lot for an "idle" process.
With a modal (options) dialog kept open, the context switch delta is usually
around 650 transitions per second.

Windows makes a transition to kernel mode for each window handling call but
does not seem to suffer performance-wise.
The reason is simple: on modern CPUs, ring3 <-> ring0 transitions are usually
carried out by "fast" system calls (special "sysenter" instruction), causing
almost no CPU load.
The wine client <-> server calls/transitions - including data transfers - are
are much more "costly" (process boundaries by design) - resulting in
performance penalty.

Although the amount of emule "idle processing" is somewhat questionable (that
short paced idle intervals generate lots of unnecessary context switches) it is
perfectly valid.

So this is actually a wine performance problem (client calling into server).

There aren't much options to fix this ... either reduce the amount of wine
server calls/transitions by "caching" client calls/data (increases complexity
and probably causes sync problems/race conditions) or optimize wine server code
paths (difficult because process boundary remains).
Unfortunately wine optimization has much lower priority than implementing new
stuff/filling gaps/fixing bugs.

Another option would be to modify emule itself.
AFAIK it comes with source code.
With the right emule code modifications it should be possible to reduce idle
message processing to create less overhead (wine server calls).

Regards


-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.