On 2011/03/24 11:17, David Vasek wrote: > > > >load averages: 1.93, 1.49, 1.35 / 0 MHz > >kaffir.spa > >41 processes: 1 running, 39 idle, 1 on processor > >CPU states: 98.2% user, 0.0% nice, 1.8% system, 0.0% interrupt, 0.0% idle > >Memory: Real: 147M/196M act/tot Free: 49M Swap: 12M/600M used/tot > > I had a simple check for greater-than-zero cpuspeed in the patch > initially (and don't print anything otherwise), but I was not really > sure if that could happen at all and on what archs. It definitly > should be there. What architecture and CPU is this from? Btw, if > there are any totally misleading values, shouldn't that be corrected > by the kernel in the first place? But if the kernel doesn't know any > better, I think zero from sysctl is ok. Just my opinion.
This is on armish, but there will be others. The sysctl returns EOPNOTSUPP so it's hitting "si->cpuspeed = 0;". > If you run some automated clock control (like apmd -C), you never > know to what clock the cpu-time statistics in top(1) and systat(1) > are related to. You still don't exactly, as top(1)'s cpu-time statistics are over an interval, whereas hw.cpuspeed is instantaneous. I do think it may be useful to display this information somewhere, but I'm not convinced that top(1) is the right place. > Anyway, HW_CPUSPEED is of type int, same as is HW_SETPERF. Not int[], > only int. How could the individual cores be reported and controlled? Obviously they can't at present, the kernel would need to be extended. But if you're considering how the display might look with a hypothetical 10GHz processor, why wouldn't you want to think about how things could work with current cpu features?
