Re: PROBLEM: no cpu MHz in /proc/cpuinfo on 2.6.25.4-rt6

[Mark Hounschell <markh@compro.net>]

Mark Hounschell wrote:
> Arjan van de Ven wrote:
>> On Wed, 11 Jun 2008 12:59:24 -0400
>> Mark Hounschell <markh@compro.net> wrote:
>>
>>> Arjan van de Ven wrote:
>>>> On Wed, 11 Jun 2008 10:14:50 -0400
>>>> "linux-os (Dick Johnson)" <linux-os@analogic.com> wrote:
>>>>
>>>>> I use CPU frequency to scale the output of rdtsc when timing
>>>>> routines being optimized.
>>>> Ok this is broken in various really bad ways.
>>>>
>>>> 1) CPU frequency is very fluctuating, it changes in principle every
>>>> millisecond or more
>>> I'm curious. What do you mean by "in principle"? And why will it
>>> change?
>> ondemand governor will change the cpu frequency dynamically all the
>> time.
>> the cpu itself has a dynamic range in which it operates (at least on
>> cpus that support Intel Dynamic Acceleration technology, IDA)
>>
> 
> OK. If I am always using AMD Opteron/X64 class machines am I safe here
> when no cpu freq scaling stuff is on and I'm pinned to a particular processor?
> 
>>>> 2) the rdtsc "frequency" is conceptually unrelated to cpu
>>>> frequency. In fact, you'll be hard-pressed to buy a system today
>>>> where this relationship works....
>>>>
>>> And what do you mean by "conceptually unrelated to cpu frequency"?
>>> Is it not the clock freq that is driving the cpu and the freq at which
>>> the tsc is incremented?
>> no it is not that... at all.
>> the tsc comes from an entirely different clock, and on anything you can
>> buy today from AMD or Intel (or the last year for that matter), it's
>> fixed frequency (except in idle) irrespective of the frequency the CPU
>> is operating at!
>> it's a "time stamp counter" not a "cpu cycle counter". You can run
>> instructions faster than the tsc increment or slower. Or sometimes at
>> the same rate.
>> Which it is depends on what cpufreq/ondemand are doing and how active
>> IDA is.
>>
> 
> I was under the impression that it was the same clock on AMD Opteron and
> newer processors.
> 
> So if all this is true how and why can the kernel use it but user land is wrong
> for doing so?
> 
> Mark 
> 

Ok, what would one use besides the tsc to take a fast high-res time stamp in a kernel module that 
could also be used in user land (same time source) to for instance calculate  the
the time between an event in the kernel to an event in user land?

do_gettimeofday / gettimeofday are not really acceptable.

Mark