From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26012 invoked by alias); 13 Nov 2003 08:25:37 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 25958 invoked from network); 13 Nov 2003 08:25:35 -0000 Received: from unknown (HELO jaguar.mkp.net) (192.139.46.146) by sources.redhat.com with SMTP; 13 Nov 2003 08:25:35 -0000 Received: from jes by jaguar.mkp.net with local (Exim 3.35 #1) id 1AKCnC-0006pS-00; Thu, 13 Nov 2003 03:25:30 -0500 To: Ulrich Drepper Cc: libc-hacker@sources.redhat.com Subject: Re: ia64 clock_gettime and HP_TIMING References: <16306.21333.78785.923547@gargle.gargle.HOWL> <3FB2751B.9010302@redhat.com> From: Jes Sorensen Date: Thu, 13 Nov 2003 08:25:00 -0000 In-Reply-To: <3FB2751B.9010302@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-11/txt/msg00030.txt.bz2 >>>>> "Ulrich" == Ulrich Drepper 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