#433 CPU overload detection

Usability (114)
Matthias Urlichs

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


    • labels: --> Usability
    • priority: 5 --> 3
  • Logged In: YES

    Is that a single CPU system?

  • Logged In: YES

    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

    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

    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.