[procps] Re: C-States handling - new switch?
- From: Jim Warner <james.warner@xxxxxxxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Tue, 7 Feb 2012 11:33:55 -0600
On Feb 7, 2012, at 11:12 AM, Jaromir Capik wrote:
>> Relax, Jaromir. It's always been that way.
>
> I hope You didn't take that as an offence.
No, not at all. It's just that you seemed to be getting a little anxious.
> Is it really only for one cycle? Can we be sure that something
> like throttling can't appear? (and possibly with future CPUs?).
>
> I'll definitely need to play with that once I get access
> to the lab systems with Nahalem.
Yep, just one cycle.
For reassurance, keep in mind that top tracks total tics (since boot) for each
cpu as well as the summary line. When a cpu is added or removed top's whole
array gets reallocated and zeroed out. So the next cycle it appears that a
whopping amount of tics had somehow occurred.
But that's ok since he scales each cpu's huge apparent delta at display time.
> Customers will say it's ok, because their assumptions were based
> on too noticeable values, which are now suppressed by the change
> You've made, but the values might be still incorrect and it could
> take ages to recognize that.
Think of the percentages as just an extrapolation/approximation.
For example, when the delay is zero, all you see is 100% jumping around the
various categories since only a single tic has been registered for each cpu.
That is clearly a fib but could/should it be represented any other way?
> I hope You're not upset or something ... I still believe it's
> an open discussion.
I am absolutely not upset and to prove it I wish to thank you once again for
your discovery...
Regards,
Jim
Other related posts:
