Re: ia64 clock_gettime and HP_TIMING

[Jes Sorensen <jes at trained-monkey dot org>]

>>>>> "Ulrich" == Ulrich Drepper <drepper@redhat.com> writes:

Ulrich> Jes Sorensen wrote:
>> I fixed this for glibc-2.2 a while ago by making HP_TIMING() call
>> gettimeofday() which is fine (patch below) as with the fast system
>> calls on ia64 it's about 150 cycles.

Ulrich> That's bogus.  The HP stands for high precision, nothing
Ulrich> gettimeofday can provide.

In that case we should simply not provide HP timing on ia64.

Ulrich> The assumption when starting to use itc was that it is
Ulrich> synchronized.  And this seems to be the case for reasonable
Ulrich> machines.  Just not these NUMA abominations.  So the solution
Ulrich> is: use nothing related to this clock on NUMA machines.  Maybe
Ulrich> build a separate libc version (similar to x86 without TSC).

This is currently a problem on the big NUMA systems but it is also
going to be a problem on the much smaller but still > 4 CPU systems,
which will be coming from many vendors. Requiring a seperate library
for this is going to be hell, it will break binary compatibility!
The machines are all running the same version of the Linux kernel,
they should be able to run the same userland.

True they killed the TSC for x86, but quite frankly those x86 machines
are extremely rare and the Linux port to those hasn't seen a lot, if
any, real end-user exposure.

I don't know the situation on Opteron, anyone know how they are going
to behave when they go beyond 2 CPUs?

Jes