[procps] Re: C-States handling - new switch?

On Jan 31, 2012, at 7:09 PM, Craig Small wrote:
> I'm not sure if that is the one that is incorporated.
> Could you try a 3.3.x top on your system to see if the problem goes
> away?

Hi Craig,

Jaromir's problem would have persisted even under a 3.3.2 top.  It is a serious 
flaw, though not exactly top's fault.

The attached tarball fixes that problem and a few others.  The patches were 
based on the most recent master (Merge remote-tracking branch 'sami/vapier').

Thanks in advance for committing them.


On Feb 1, 2012, at 6:09 AM, Jaromir Capik wrote:
>> Anyway, I've got more research to do...
> :] Please, tell us once You have any results ... 

Hi Jaromir,

As promised yesterday, here's my proposed solution for the Nehalem anomaly.  
The patch for that one issue essentially boiled down to two lines of code.

My research suggests the 1st /proc/stat line (the top cpu summary) will always 
produce reliable percentages.  It does not appear to be distortable by the 
scenario described in 
http://www.freelists.org/post/procps/CStates-handling-new-switch,4. 

The following new top calculation yields 10% of total elapsed tics divided by 
that elusive kernel 'HZ' (or 'Hertz' in libprocps-speak).  
  (smp_num_cpus * 10) * Rc.delay_time)

Using that sliding value as a threshold, cpus with fewer total tics now show as 
100% idle whereas those with at least that amount get the usual individually 
scaled percentages.  With more tics to spread around a cpu should not display 
those "too round" percentages you experienced, except at very small delay 
intervals which is appropriate.

I'll be very interested in your feedback once the revised top has been run 
under a real Nehalem machine.  We may yet need to fine tune this new tics 
threshold.  However, with the current algorithm, my testing produces a very 
natural sliding granularity under a variety of delay intervals and available 
cpus.

For anybody who wishes to assist in verifying this fix, there are some tools 
that can be useful.  This was my first exposure to them.
. toggling cpus offline (echo 0 > /sys/devices/system/cpu/cpuX/online)
. tweaking the CPUFreq subsystem (cpufreq-set, cpufreq-info)
. fixing process cpu affinity (taskset)

Thanks, Jaromir, for your discovery and the opportunity to make top better.

Regards,
Jim

Other related posts: