sched_clock() on i386

[Stephane Eranian <eranian@hpl.hp.com>]

Hello,


The perfmon subsystems needs to compute per-CPU duration. It is using
sched_clock() to provide this information. However, it seems they are
big variations in the way sched_clock() is implemented for each architectures,
especially in the accuracy of the returned value (going from TSC to jiffies).

Looking at the i386 implementation, it is not so clear to me what the
actual goal of the function is. I was under the impression that this
function was meant to compute per-CPU time deltas. This is how the
scheduler seems to use it. 

The x86-64 and i386 implementations are quite different. The i386 comment
about NUMA seems to contradict the initial goal of the function.
Why is that?

Does this come from the fact that sched_lock() is used for the time-stamping
printk(). But in this case, like on IA-64, couldn't we define a specific
timing function for printk?


Excerpt from arch/i386/kernel/tsc.c:

unsigned long long sched_clock(void)
{
        unsigned long long this_offset;

        /*
         * in the NUMA case we dont use the TSC as they are not
         * synchronized across all CPUs.
         */
#ifndef CONFIG_NUMA
        if (!cpu_khz || check_tsc_unstable())
#endif
                /* no locking but a rare wrong value is not a big deal */
                return (jiffies_64 - INITIAL_JIFFIES) * (1000000000 / HZ);

        /* read the Time Stamp Counter: */
        rdtscll(this_offset);

        /* return the value in ns */
        return cycles_2_ns(this_offset);
}


-- 
-Stephane
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/