[procps] Re: C-States handling - new switch?
- From: Jim Warner <james.warner@xxxxxxxxxxx>
- To: procps@xxxxxxxxxxxxx
- Date: Wed, 8 Feb 2012 11:10:32 -0600
On Feb 8, 2012, at 10:50 AM, Jaromir Capik wrote:
>> Not any more, since we're now based on actual elapsed tics.
>>
>> Whatever tics are available, they'll be scaled to the range of
>> 0-100%. Assuming, of course, a category exceeds the arbitrary
>> (maybe future-tunable) 10% threshold.
>
> Sorry ... but this sounds to me like an exact opposite.
> If we scale the values according to the total available ticks,
> then the same load in case of halved frequency must look 2x higher.
> Because the process steals the same amount of ticks, but the
> total ticks are halved.
> So ... if I understand that correctly, this kind of scaling
> produces the distortion. I believe, that majority of users aren't
> interested in load related to the actual frequency, but they're
> interested in load related to the maximum frequency, since it
> defines how much of speed reserves the CPU actually has.
> And I can also imagine two groups of people each wanting
> a different behavior. And that smells like need for a new switch.
Sorry, but I misspoke. What's new is the approach to potentially 'off' vs.
'idle' cpus and that is now based on elapsed tics. As such, it doesn't matter
what the cpu frequency or kernel HZ is.
The scaling I describe has been been unchanged for the past 10+ years. It
represents the relative activity for a single cpu. Why are you questioning it
only now?
Under procps-ng top, the Cpu2 example you've been using would show 100% idle
consistently.
If you imagine these values are distorted, don't use the '1' toggle. Show only
summary level cpu activity.
Are you sure you're not pursuing a non-existent problem?
Jim
Other related posts:
