library: fix an insidious bug affecting TICS_ALL_DELTA

This simple two line code change fixes an intermittent
bug whereby %CPU for parent(s) with collapsed children
could be vastly understated from those displayed under
the current 3.3.17 publicly available top & libprocps.

If one started several top instances in the background
using very a small delay interval (zero?), then if the
shell under which they were running was collapsed, you
would see similar %CPU results for both the libraries.

However, when running a demanding 'make' like a kernel
compile (especially if backed by fast processors and a
SSD), then newlib would generally show only 1/3 to 1/2
of the collapsed %CPU values that appeared for 3.3.17.

Of course, now that the bug has been swatted with this
commit the disparities between those results is easily
explained. Since newly created tasks never contributed
tics during the interval where they were created, only
with many short lived tasks would differences surface.

Signed-off-by: Jim Warner <james.warner@comcast.net>

diff --git a/proc/pids.c b/proc/pids.c
index 77e5b071826b8101dffd92d68768fa8dfa5f0aa9..62a4a83b69cab60d0fba95977fd44900bd92316a 100644 (file)
--- a/proc/pids.c
+++ b/proc/pids.c
@@ -645,10 +645,13 @@ static inline int pids_make_hist (
     pids_histput(info, slot);
 
     if ((h = pids_histget(info, p->tid))) {
-        p->pcpu = tics - h->tics;
+        tics -= h->tics;
         p->maj_delta = p->maj_flt - h->maj;
         p->min_delta = p->min_flt - h->min;
     }
+    /* here we're saving elapsed tics, which will include any
+       tasks not previously seen via that pids_histget() guy! */
+    p->pcpu = tics;
 
     info->hist->num_tasks++;
     return 1;