> > Lastly, exporting the real CPU cycle time to /proc/cpuinfo. Not a
> > difficult thing: we've got init_timer_cc, last_timer_cc, and jiffies in
> > memory -- not to mention cached_quotient sitting around. The hairy thing
> > is that this information is probably not available on all architectures,
> > and exporting the relevant data in a architecture-independent manner will
> > probably be hairy. Not impossible, but it will have to be done carefully
> > and cleanly if it's going to make it past Linus.
>
> if (machine_supports_tsc)
> show_MegaHertz_rating
> else
> show_Bogomips_rating
>
> should go a long way to solve the confusion in many people's minds about
> bogomips, MHz and CPU performance...
No. Please show bogomips every time: we are not interested how fast
cpu clock is, we are interested how fast it performs. And bogomips
indicator already shown few performance leaks to me (like L1 cache
off), which would be undetected by MHz rating as MHz do not depend on
L1 setting.
> Bogomips should be kept internally because there is kernel code that
> still depends on it for accurate timing, I think. Reporting it in
> /proc/cpuinfo is another issue, IMHO.
Please keep it. If someone wants to know MHz, get that userland
utility. But keep bogomips in kernel.
Pavel
-- The best software in life is free (not shareware)! Pavel GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu