[procps] Re: C-States handling - new switch?
- From: Jaromir Capik <jcapik@xxxxxxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Wed, 01 Feb 2012 05:18:52 -0500 (EST)
> 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 guys.
Craig,
The results sent by me were collected using the 3.3.2 version.
I've checked the source and the patch is identical to the
corresponding part of the procps-ng code.
So ... we probably need to redesign that and it could be quite
difficult if there's no easy way how to get the maximum
possible increment (I've read the /proc/stat docs and
it's USUALLY in hundredths of seconds, but can we be sure
about that? I don't think so). If the value is not included
in the /proc system, then we would need to do some initial
calibration by loading at least 1 CPU core per group
(for systems equipped with two or more different CPUs)
to it's maximum and store the collected values
in a configuration/data file. If the maximum value is
always defined by the CPU model, then we could eventually
create a database of known CPUs, holding the maximum values
and the calibration would be done only for CPUs missing
in the database.
I'd like to do some tests here in order to learn how
it behaves.
Please, let me know if You find that reasonable or
if it sounds like bullshits.
Thanks,
Jaromir.
>
> 0 Craig
>
> --
> Craig Small VK2XLZ http://enc.com.au/ csmall at :
> enc.com.au
> Debian GNU/Linux http://www.debian.org/ csmall at :
> debian.org
> GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50
> FEA5
>
>
Other related posts: