top: update latest CPU % distortions understanding

We originally approached the potential problem of
% CPU distortions as unique to Nehalem type cpus.
The latest information suggests that it may have
been due to a kernel anomaly that has since been
corrected.

Yet even without such a cpu, wide disparities in
tics allocation among all available cpus have
sometimes been observed -- spikes as it were in
the normal pattern.  This has happened under both
version 2.26.38-13 and 3.0.0-15 kernels.

The small amount of additional code addressing the
original problem carries very little overhead.  It
is being retained to afford protection against any
future tic accounting aberrations.

In this commit, supporting programmer comments have
been divorced from any particular cpu type.  Also,
another variable and manifest constant will now be
eliminated when CPU_ZEROTICS is defined.

References:
commit 02508b3d76af5bc33c7e559b84d3e5e123cdf2ac
http://www.freelists.org/post/procps/CStates-handling-new-switch,50

top/top.c

@@ -1836,14 +1836,13 @@ static CPU_t *cpus_refresh (CPU_t *cpus) {
       , &cpus[Cpu_faux_tot].cur.i, &cpus[Cpu_faux_tot].cur.w, &cpus[Cpu_faux_tot].cur.x
       , &cpus[Cpu_faux_tot].cur.y, &cpus[Cpu_faux_tot].cur.z))
          error_exit(N_txt(FAIL_statget_txt));
+#ifndef CPU_ZEROTICS
    cpus[Cpu_faux_tot].cur.tot = cpus[Cpu_faux_tot].cur.u + cpus[Cpu_faux_tot].cur.s
       + cpus[Cpu_faux_tot].cur.n + cpus[Cpu_faux_tot].cur.i + cpus[Cpu_faux_tot].cur.w
       + cpus[Cpu_faux_tot].cur.x + cpus[Cpu_faux_tot].cur.y + cpus[Cpu_faux_tot].cur.z;
-#ifndef CPU_ZEROTICS
+   /* if a cpu has registered substantially fewer tics than those expected,
-   /* if a Nehalem type cpu has been turned off completely, and thus registers
+      we'll force it to be treated as 'idle' so as not to present misleading
-      very few total tics, we'll force it to be treated as idle when that total
+      percentages. */
-      falls below a % of those expected -- other cpus will register their full
-      number of expected tics as 'idle' and thus won't be effected */
    cpus[Cpu_faux_tot].edge =
       ((cpus[Cpu_faux_tot].cur.tot - cpus[Cpu_faux_tot].sav.tot) / smp_num_cpus) / (100 / TICS_EDGE);
 #endif
@@ -1866,9 +1865,9 @@ static CPU_t *cpus_refresh (CPU_t *cpus) {
       }
 #ifndef CPU_ZEROTICS
       cpus[i].edge = cpus[Cpu_faux_tot].edge;
-#endif
       // this is for symmetry only, it's not currently required
       cpus[i].cur.tot = cpus[Cpu_faux_tot].cur.tot;
+#endif
 #ifdef PRETEND4CPUS
       cpus[i].id = i;
 #endif

top/top.h

@@ -62,9 +62,9 @@
            for nls support inclusion.  They're identified with:
               // nls_maybe */
 
-        /* For initiating the topic of potential % CPU distortions due
+        /* For initiating the topic of potential % CPU distortions due to
-           to Nehalem type processors (see CPU_ZEROTICS), thanks to:
+           to kernel and/or cpu anomalies (see CPU_ZEROTICS), thanks to:
-               Jaromir Capik, <jcapik@redhat.com> - February, 2012 */
+              Jaromir Capik, <jcapik@redhat.com> - February, 2012 */
 
 #ifdef PRETEND2_5_X
 #define linux_version_code LINUX_VERSION(2,5,43)
@@ -133,10 +133,12 @@
            -- used at startup and for task/thread mode transitions */
 #define PROC_XTRA  -1
 
+#ifndef CPU_ZEROTICS
         /* This is the % used in establishing the tics threshold below
            which a cpu is treated as 'idle' rather than displaying
            misleading state percentages */
 #define TICS_EDGE  20
+#endif
 
 
 /* #####  Enum's and Typedef's  ############################################ */
@@ -223,7 +225,9 @@ typedef struct CT_t {
       2.6.0  kernel: x == hi (hardware irq time), y == si (software irq time)
       2.6.11 kernel: z == st (virtual steal time) */
    TIC_t u, n, s, i, w, x, y, z;  // as represented in /proc/stat
+#ifndef CPU_ZEROTICS
    SIC_t tot;                     // total from /proc/stat line 1
+#endif
 } CT_t;
 
 typedef struct CPU_t {