Menu
▾
▴
#433 CPU overload detection
I happen to run gtk-gnutella on a system with slow disk.
The system load frequently reaches 10 on that box, but
all of these processes are in D state.
gnutella still thinks there's overload and throttles
its UI updates. That's nonsense, there's no CPU
shortage on the system.
The right thing to do, at least on Linux systems, would
be to check /proc/stat for free idle time. Mine says,
among other interesting lines:
cpu 6195644 181441 470620 37216047 2006403 27167 87753 0
The fourth number is the (cumulative) idle time in the
system. If it increases by more than 10 per second or
so, then the system is not busy.
You can also check /proc/self/status. The SleepAVG
parameter says how often a process released its
scheduled time voluntarily (by waiting). If that's near
zero, you may throttle yourself, otherwise there's no
point.
Logged In: YES
user_id=643728
Is that a single CPU system?
Logged In: YES
user_id=13887
Oerloading detection does not only take into account CPU
usage -- if the callout queue callback gets less than 10
schedules per second, then it means someone is stealing CPU
from GTKG and it does not get enough.
So CPU overloading may trigger if some other process
prevents GTKG from executing its code in a timely fashion.
Logged In: YES
user_id=643728
For your information, the effect of the overload detection
has been relaxed at while ago in SVN. That means background
tasks like SHA-1 calculation are no longer suspended, they
just get less CPU time. Literally "CPU overloaded" is of
course incorrect in your case but the effect is the same no
matter whether it's CPU-excessive GUI code or blocking
hardware. As Gtk-Gnutella isn't multi-threaded and doesn't
use multi-processing either (well except for DNS), the whole
application will of course suffer and stall if I/O blocks.
Usually disk I/O is consider sufficiently fast that this
never a concern except for high-speed transfers maybe.
We cannot make your disk faster, so my question would be,
is the GUI unusable on your system or is it just the
misdetection that bothers you? Solving this completely would
require some massive non-trivial changes. Possible solutions
are:
1. Async disk I/O; requires support by the OS
2. Multi-threading: Use a dedicated thread for I/O; if it
blocks everything else gets still scheduled
3. Multi-processing: Use a backend process and a GUI process.
Or maybe a combination of those. Though option 3 would only
solve it on the surface i.e., the network I/O would still
suffer from blocking disk I/O which is at least as much of a
concern as a unresponsive GUI. So maybe using a
process dedicated to disk I/O along with shared memory would
be required.
Async I/O might be the least intrusive but is not widely
supported or even used, thus might be buggy or have not
well-known gotchas.