emo/procps
1
0
Fork 0
Code Issues Pull Requests Packages Releases Activity

top: update latest CPU % distortions understanding

Browse Source 
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 02508b3d76
http://www.freelists.org/post/procps/CStates-handling-new-switch,50
This commit is contained in:
Jim Warner 2012-02-10 15:15:15 -06:00 committed by Craig Small
parent ccb5144050
commit ee3ed4b45e
2 changed files with 12 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
top/top.c
View File

@ -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 Nehalem type cpu has been turned off completely, and thus registers
very few total tics, we'll force it to be treated as idle when that total
falls below a % of those expected -- other cpus will register their full
number of expected tics as 'idle' and thus won't be effected */
/* if a cpu has registered substantially fewer tics than those expected,
we'll force it to be treated as 'idle' so as not to present misleading
percentages. */
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

10
top/top.h
View File

@ -62,9 +62,9 @@
for nls support inclusion. They're identified with:
// nls_maybe */
/* For initiating the topic of potential % CPU distortions due
to Nehalem type processors (see CPU_ZEROTICS), thanks to:
Jaromir Capik, <jcapik@redhat.com> - February, 2012 */
/* For initiating the topic of potential % CPU distortions due to
to kernel and/or cpu anomalies (see CPU_ZEROTICS), thanks to:
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 {