[procps] Re: C-States handling - new switch?
- From: Jaromir Capik <jcapik@xxxxxxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Tue, 07 Feb 2012 08:01:40 -0500 (EST)
> Hi Jaromir,
>
Hi Jim.
> 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.
>
that's great !
> 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
> //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.
I'll try to redistribute the fix to our customers and collect their
feedback. This could take some time ... hopefully not more than
2 months.
>
> 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.
You know ... opensource is my life :] And I see the new procps-ng
upstream as something really crucial. So ... as You see, it's also
my selfish need to make the things better (or perfect?) :D
I'd like to find more time in order to get more familiar with
all the procps internals in order to contribute more in form
of patches. Hopefully this will happen soon.
>
> Regards,
> Jim
>
Regards,
Jaromir.
Other related posts: