clock_gettime, get_clockfreq

[Carlos O'Donell]

On Mon, Apr 30, 2012 at 3:02 AM, edA-qa mort-ora-y <eda-qa@disemia.com> wrote:
> I'm trying to understand how clock_gettime works and I'm uncertain as to
> how scaled CPU frequencies are handled.
>
> If I look at the clock_gettime code it calls a function call
> get_clockfreq.  This patterns is the same in multiple versions of this code.
>
> On linux this frequency is read once from the '/proc/cpuinfo' file. This
> information I believe is set only once at system startup. However,
> during operations the actual frequency will change. I can indeed get it
> to have any number of values in the cpuinfo file. How does clock_gettime
> actually resolve this issue? Does the TSC somehow automatically
> represent clock-cycles in this listed frequency?
>
> Also, I noticed a 4096 buffer in get_clockfreq which reads the timer.
> There is a counter which says proc won't produce larger files, yet I
> have system where the 'cpuinfo' file is clearly larger than this. I'm
> sure the first 4K will have a speed in it, but the speed does not need
> to be the same across all CPUs.
>
> Note: I'm looking at the x86_64 code for Linux.

As far as I know the high-performance timers in glibc are not accurate
but they are precise.

You must lock the process to a CPU and turn off frequency scaling to
get accurate results.

It is my opinion that the current hp-timing in glibc for x86 and
x86_64 violates POSIX in a system where scheduling to a new CPU would
mean _dl_cpuclock_offset is wrong, and where frequency scaling
invalidates the cached frequency read from /proc.

I am by no means an expert on x86, but I've always been leery of the
glibc implementation being wrong.

You may wish to re-ask this question on libc-alpha:

* Ask the question again.

* Post example code that shows conclusively that this code doesn't
work if your process migrates to a new CPU or if the CPU scales the
frequency.

Cheers,
Carlos.