If I use jiffies global variable, very often I get two identical values before and after the function call. I need more accurate stamps. Now, with rdtscll I get these values but in cycles. This measurement is for the same machine, so if I could have the cpu MHz I could do the division. Am I right?
Now the question is how to get cpu MHz. The cpuinfo_x86 structure has not this field. I try to keep track for the value showed by /proc/cpuinfo. But at arc/i383/kernel/cpu/proc.c I see the following sentence:
if ( cpu_has(c, X86_FEATURE_TSC) ) {
seq_printf(m, "cpu MHz\t\t: %u.%03u\n",
cpu_khz / 1000, (cpu_khz % 1000));
But cpu_khz is not declared in this file.... even as extern.
Any ideas to get cpu MHz (or KHz) in order to convert cycles to time units?
Thanks in advance.
On 6/29/06, Arjan van de Ven <
arjan@xxxxxxxxxxxxx> wrote:
On Wed, 2006-06-28 at 17:29 +0200, Fernando Apesteguía wrote:
> Hi,
>
> I would like to take some time measurements for some functions from my
> kernel module. In a first attempt, I tried to use current_kernel_time,
> but this often returns the same value before and after the call I want
> to measure (even, when I use the tv_nsec field.).
>
> ts1=current_kernel_time;
> function();
> ts2=current_kernel_time;
>
> So now I'm using rdtscll instead of current_kernel_time and that's
> fine.. but I would like to convert that cycle units to time units. I
> don't know how to do it... Maybe with loops_per_jiffies and do_div but
> I don't know how to combine them. What is a jiffie (4 ms as wikipedia
> said in 2.6 kernel series) and how can I use them to convert the
> rdtscll return value to time units?
well there is no fixed way to do that... for example, cpu frequencies
are not constant anymore since a few years, and on several cpus the
rdtsc timer even stops entirely when in the idle loop... so..
correlating rdtsc to wallclock time is always going to be real iffy.
there is a cpu_khz variable that you can use as best guestimate if you
can live with all these problems..... which sort of is an estimate the
number of clock ticks in kiloHertz. But again... what you'll get isn't
going to be very accurate since your "clock" is too volatile for that.
