ia64 clock_gettime and HP_TIMING

ia64 clock_gettime and HP_TIMING

[Jes Sorensen]

Hi

I am looking at a problem with the current implementation of HP_TIMING
on ia64.

The problem is that HP_TIMING uses the ITC (similar to the x86 TSC)
which isn't synchronized across nodes, hence in a multi-node NUMA system
you can get the situation where HP_TIMING() goes backwards.

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.

Now my question is what one should do wrt clock_gettime(). The
implementation in CVS uses HP_TIMING() for CLOCK_PROCESS_CPUTIME_ID,
however I was curious if I could just switch that to calling
sys_clock_gettime() directly and then use gettimeofday() as a fall-back?

Any oppinions/suggestions?

Thanks,
Jes

2003-03-21  Jes Sorensen  <jes@wildopensource.com>

	* libc-2.3/sysdeps/ia64/hp-timing.h: Migrate HP_TIMING_NOW() to
	use gettimeofday(). Adjust HP_TIMING_PRINT() accordingly.
	* libc-2.3/sysdeps/unix/sysv/linux/ia64/get_clockfreq.c: Timing
	clock is now in micro seconds, independant of the CPU clock.

--- glibc-2.3.2-vanilla/sysdeps/ia64/hp-timing.h	Sat Aug 24 20:59:22 2002
+++ glibc-2.3.2/sysdeps/ia64/hp-timing.h	Tue Nov 11 07:36:23 2003
@@ -1,5 +1,5 @@
 /* High precision, low overhead timing functions.  IA-64 version.
-   Copyright (C) 2001, 2002 Free Software Foundation, Inc.
+   Copyright (C) 2001, 2002, 2003 Free Software Foundation, Inc.
    This file is part of the GNU C Library.
    Contributed by Ulrich Drepper <drepper@cygnus.com>, 2001.
 
@@ -25,6 +25,7 @@
 #include <sys/param.h>
 #include <stdio-common/_itoa.h>
 #include <ia64intrin.h>
+#include <sys/time.h>
 
 /* The macros defined here use the timestamp counter in IA-64.  They
    provide a very accurate way to measure the time with very little
@@ -88,15 +89,23 @@
    processor implementation.  */
 #define REPEAT_READ(val) __builtin_expect ((int) val == -1, 0)
 
-/* That's quite simple.  Use the `ar.itc' instruction.  */
-#define HP_TIMING_NOW(Var) \
-  ({ unsigned long int __itc;						      \
-     do									      \
-       asm volatile ("mov %0=ar.itc" : "=r" (__itc) : : "memory");	      \
-     while (REPEAT_READ (__itc));					      \
-     Var = __itc; })
+#define HP_TIMING_NOW(Var) (Var = __hp_timing_now())
 
-/* Use two 'ar.itc' instructions in a row to find out how long it takes.  */
+static inline hp_timing_t
+__hp_timing_now(void)
+{
+  hp_timing_t val = 0;
+  struct timeval tv;
+  int status;
+
+  status = gettimeofday (&tv, NULL);
+  if (!status)
+    val = (hp_timing_t) tv.tv_usec;
+
+  return (hp_timing_t) val;
+}
+
+/* Call twice in a row to find out how long it takes.  */
 #define HP_TIMING_DIFF_INIT() \
   do {									      \
     int __cnt = 5;							      \
@@ -141,8 +150,8 @@
     char *__dest = (Buf);						      \
     while (__len-- > 0 && __cp < __buf + sizeof (__buf))		      \
       *__dest++ = *__cp++;						      \
-    memcpy (__dest, " clock cycles", MIN (__len,			      \
-					  (int) sizeof (" clock cycles")));   \
+    memcpy (__dest, " micro seconds", MIN (__len,			      \
+					  (int) sizeof (" micro seconds")));  \
   } while (0)
 
 #endif	/* hp-timing.h */
--- glibc-2.3.2-vanilla/sysdeps/unix/sysv/linux/ia64/get_clockfreq.c	Sat Jul  7 12:21:34 2001
+++ glibc-2.3.2/sysdeps/unix/sysv/linux/ia64/get_clockfreq.c	Tue Nov 11 07:35:28 2003
@@ -1,5 +1,5 @@
 /* Get frequency of the system processor.  IA-64/Linux version.
-   Copyright (C) 2001 Free Software Foundation, Inc.
+   Copyright (C) 2001, 2003 Free Software Foundation, Inc.
    This file is part of the GNU C Library.
 
    The GNU C Library is free software; you can redistribute it and/or
@@ -27,63 +27,5 @@
 hp_timing_t
 __get_clockfreq (void)
 {
-  /* We read the information from the /proc filesystem.  It contains at
-     least one line like
-	itc MHz    : 733.390988
-     We search for this line and convert the number in an integer.  */
-  static hp_timing_t result;
-  int fd;
-
-  /* If this function was called before, we know the result.  */
-  if (result != 0)
-    return result;
-
-  fd = open ("/proc/cpuinfo", O_RDONLY);
-  if (__builtin_expect (fd != -1, 1))
-    {
-      /* XXX AFAIK the /proc filesystem can generate "files" only up
-         to a size of 4096 bytes.  */
-      char buf[4096];
-      ssize_t n;
-
-      n = read (fd, buf, sizeof buf);
-      if (__builtin_expect (n, 1) > 0)
-	{
-	  char *mhz = memmem (buf, n, "itc MHz", 7);
-
-	  if (__builtin_expect (mhz != NULL, 1))
-	    {
-	      char *endp = buf + n;
-	      int seen_decpoint = 0;
-	      int ndigits = 0;
-
-	      /* Search for the beginning of the string.  */
-	      while (mhz < endp && (*mhz < '0' || *mhz > '9') && *mhz != '\n')
-		++mhz;
-
-	      while (mhz < endp && *mhz != '\n')
-		{
-		  if (*mhz >= '0' && *mhz <= '9')
-		    {
-		      result *= 10;
-		      result += *mhz - '0';
-		      if (seen_decpoint)
-			++ndigits;
-		    }
-		  else if (*mhz == '.')
-		    seen_decpoint = 1;
-
-		  ++mhz;
-		}
-
-	      /* Compensate for missing digits at the end.  */
-	      while (ndigits++ < 6)
-		result *= 10;
-	    }
-	}
-
-      close (fd);
-    }
-
-  return result;
+  return (hp_timing_t) 1000000;
 }

Re: ia64 clock_gettime and HP_TIMING

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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

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


> Now my question is what one should do wrt clock_gettime(). The
> implementation in CVS uses HP_TIMING() for CLOCK_PROCESS_CPUTIME_ID,
> however I was curious if I could just switch that to calling
> sys_clock_gettime() directly and then use gettimeofday() as a fall-back?

This question has been obsoleted by the comment above.  You cannot use
gettimeofday or the clock_* syscalls for it.

- -- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/snUb2ijCOnn/RHQRAn+uAKDKRhmLBe4nstj+gPqSd5vfUmdp8wCfZWkh
NGazQ38hQ+0siy2qSoRinaM=
=Sowo
-----END PGP SIGNATURE-----

Re: ia64 clock_gettime and HP_TIMING

[Jes Sorensen]

>>>>> "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

Re: ia64 clock_gettime and HP_TIMING

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jes Sorensen wrote:

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

"Oh, I cannot provide a feature for the machines I'm using.  That means
 nobody must use it."

The HP clocks are extremely useful.  They stay.

- -- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/s0ta2ijCOnn/RHQRAstMAJ9kL2fo6RWQ07qS0cfehVLhrCVNOACfV2IH
iJLp0VGqidPl7pfQ/mTu4pQ=
=zunC
-----END PGP SIGNATURE-----

Re: ia64 clock_gettime and HP_TIMING

[Jes Sorensen]

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

Ulrich> Jes Sorensen wrote:
>> In that case we should simply not provide HP timing on ia64.

Ulrich> "Oh, I cannot provide a feature for the machines I'm using.
Ulrich> That means nobody must use it."

This is a general problem on a large number of ia64 machines. Relying
on the ITC in userland without checking /proc/sal/itc_drift first is
simply broken.

Ulrich> The HP clocks are extremely useful.  They stay.

I am not saying that should go, I am just asking we come up with a
solution that means our binaries return an error rather return
unreliable data.

How do you feel about a solution where we add a runtime check against
/proc/sal/itc_drift and handle it appropriately within the HP_TIMING
macros?

Cheers,
Jes

Re: ia64 clock_gettime and HP_TIMING

[David Mosberger]

>>>>> On 13 Nov 2003 08:27:40 -0500, Jes Sorensen <jes@trained-monkey.org> said:

  Ulrich> The HP clocks are extremely useful.  They stay.

  Jes> I am not saying that should go, I am just asking we come up
  Jes> with a solution that means our binaries return an error rather
  Jes> return unreliable data.

  Jes> How do you feel about a solution where we add a runtime check
  Jes> against /proc/sal/itc_drift and handle it appropriately within
  Jes> the HP_TIMING macros?

All platforms with drifting cycle-counters have a common
(CPU-external) high-precision timer, so shouldn't you be using that
instead of returning an error?

I didn't get Uli's point about gettimeofday() not being sufficiently
accurate, though.  True, the current light-weight gettimeofday() does
only ITC-based interpolation (and falls back on heavy-weight syscall
otherwise), but that still gives rather high precision
(sub-microsecond, at least).  Moreover, I don't see any reason why the
light-weight system call couldn't be extended to support HPET and
perhaps SGI's timer (since they never seem to use standardized
hardware... ;-/ ).  Whether or not the resulting gettimeofday() would
be sufficient for HP_TIMING purposes, I don't know.

	--david

Re: ia64 clock_gettime and HP_TIMING

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David Mosberger wrote:

> I didn't get Uli's point about gettimeofday() not being sufficiently
> accurate, though.

This is only about the clock_* functions with the CPUCLOCK selected or
the internal uses of HP clocks.  For this gettimeofday is not adequate.

- -- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/tBF+2ijCOnn/RHQRAtWrAKC0f61ZD9ILVF9KVwooLSUlp9dX5wCghBnD
XsSp+yz5pLQX42sHEAArbuk=
=e0ot
-----END PGP SIGNATURE-----

Re: ia64 clock_gettime and HP_TIMING

[Jes Sorensen]

>>>>> "David" == David Mosberger <davidm@napali.hpl.hp.com> writes:

>>>>> On 13 Nov 2003 08:27:40 -0500, Jes Sorensen <jes@trained-monkey.org> said:
Ulrich> The HP clocks are extremely useful.  They stay.

Jes> How do you feel about a solution where we add a runtime check
Jes> against /proc/sal/itc_drift and handle it appropriately within
Jes> the HP_TIMING macros?

David> All platforms with drifting cycle-counters have a common
David> (CPU-external) high-precision timer, so shouldn't you be using
David> that instead of returning an error?

Can you point me to some specs for that and I'll take a look at
cooking up a patch?

David> Moreover, I don't see any reason why the light-weight system
David> call couldn't be extended to support HPET and perhaps SGI's
David> timer (since they never seem to use standardized
David> hardware... ;-/ ).  Whether or not the resulting gettimeofday()
David> would be sufficient for HP_TIMING purposes, I don't know.

I'll see what I can come up with patch wise for something that allows
the HP_TIMING to be flagged as available/unavailable runtime as well
as supporting the HPET (if I can find info about it somewhere). Should
be pretty easy to setup something the first time get_clockfreq() is
called. Not knowing enough about HPET, my biggest worry is if we have
to open up an extra file descriptor for a permanent mmap of it.

Cheers,
Jes

Re: ia64 clock_gettime and HP_TIMING

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jes Sorensen wrote:
> Not knowing enough about HPET, my biggest worry is if we have
> to open up an extra file descriptor for a permanent mmap of it.

One immediately closes the filedescriptor after the mmap call if this
mmaped region is all that is needed.

- -- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE/tRXc2ijCOnn/RHQRAmzUAJ4ibRqrJnVNFenvZXS1r+BlVpFirQCfWUCZ
0fMD7rXw2Fj7/9Tg8yBKNYI=
=oeif
-----END PGP SIGNATURE-----

Re: ia64 clock_gettime and HP_TIMING

[David Mosberger]

Jes,

>>>>> On 14 Nov 2003 04:36:55 -0500, Jes Sorensen <jes@trained-monkey.org> said:

>>>>> "David" == David Mosberger <davidm@napali.hpl.hp.com> writes:
>>>>> On 13 Nov 2003 08:27:40 -0500, Jes Sorensen <jes@trained-monkey.org> said:
  David> All platforms with drifting cycle-counters have a common
  David> (CPU-external) high-precision timer, so shouldn't you be
  David> using that instead of returning an error?

  Jes> Can you point me to some specs for that and I'll take a look at
  Jes> cooking up a patch?

I suspect you may have found it in the meantime, but if not, googling for
"hpet specification" yields:

   http://www.intel.com/labs/platcomp/hpet/hpetspec.htm

	--david

Re: ia64 clock_gettime and HP_TIMING

[Jes Sorensen]

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

Ulrich> Jes Sorensen wrote:
>> Not knowing enough about HPET, my biggest worry is if we have to
>> open up an extra file descriptor for a permanent mmap of it.

Ulrich> One immediately closes the filedescriptor after the mmap call
Ulrich> if this mmaped region is all that is needed.

Ok, what about something like this, it makes clock_getcpuclokcid()
return ENOENT if the itc drifts. I left __itc_drift_internal as a
global variable as I am not sure whether clock_gettime should be
change to check it as well before allowing a call for
CLOCK_PROCESS_CPUTIME_ID.

I still want to look into supporting the HPET and SN2 RTC at a later
stage.

Cheers,
Jes


2003-12-01  Jes Sorensen  <jes@wildopensource.com>

	* rt/tst-clock.c (do_test): Print message when skipping
	CLOCK_PROCESS_CPUTIME_ID test.
	* sysdeps/unix/sysv/linux/ia64/clock_getcpuclockid.c: New file.
	Provide CLOCK_PROCESS_CPUTIME_ID only if /proc/sal/itc_drift is 0.

--- libc-old/rt/tst-clock.c	6 Jul 2001 04:55:39 -0000	1.3
+++ libc-2.3/rt/tst-clock.c	1 Dec 2003 14:52:07 -0000
@@ -113,6 +113,8 @@
   if (clock_getcpuclockid (0, &cl) == 0)
     /* XXX It's not yet a bug when this fails.  */
     clock_test (cl);
+  else
+	  printf("CPU clock unavailble, skipping test\n");
 
   return result;
 }
--- /dev/null	Wed Dec 31 16:00:00 1969
+++ libc-2.3/sysdeps/unix/sysv/linux/ia64/clock_getcpuclockid.c	Mon Dec  1 06:21:42 2003
@@ -0,0 +1,75 @@
+/* Copyright (C) 2000, 2001, 2003 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, write to the Free
+   Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+   02111-1307 USA.  */
+
+#include <errno.h>
+#include <time.h>
+#include <unistd.h>
+#include <sys/stat.h>
+#include <sys/types.h>
+#include <fcntl.h>
+
+int __itc_drift_internal;
+
+int
+clock_getcpuclockid (pid_t pid, clockid_t *clock_id)
+{
+  /* We don't allow any process ID but our own.  */
+  if (pid != 0 && pid != getpid ())
+    return EPERM;
+
+#ifdef CLOCK_PROCESS_CPUTIME_ID
+  {
+    int retval = ENOENT;
+
+    if (__builtin_expect (__itc_drift_internal == 0, 0))
+      {
+	int fd;
+
+	fd = open ("/proc/sal/itc_drift", O_RDONLY);
+	if (__builtin_expect (fd != -1, 1))
+	  {
+	    char buf[16];
+	    ssize_t n;
+	    n = read (fd, buf, sizeof buf);
+	    if (__builtin_expect (n, 1) > 0)
+	      {
+		if (buf[0] != '0')
+		  __itc_drift_internal = 1;
+		else
+		  __itc_drift_internal = -1;
+	      }
+	    close (fd);
+	  }
+	else
+	  __itc_drift_internal = -1;
+      }
+
+    if (__itc_drift_internal != 1)
+      {
+	/* Store the number.  */
+	*clock_id = CLOCK_PROCESS_CPUTIME_ID;
+	retval = 0;
+      }
+
+    return retval;
+  }
+#else
+  /* We don't have a timer for that.  */
+  return ENOENT;
+#endif
+}

Re: ia64 clock_gettime and HP_TIMING

[Jes Sorensen]

Hi,

I didn't hear anything back on this one, so I just wanted to hear if
there were any objections to this patch?

Thanks,
Jes

>>>>> "Jes" == Jes Sorensen <jes@wildopensource.com> writes:

>>>>> "Ulrich" == Ulrich Drepper <drepper@redhat.com> writes:
Ulrich> Jes Sorensen wrote:
>>> Not knowing enough about HPET, my biggest worry is if we have to
>>> open up an extra file descriptor for a permanent mmap of it.

Ulrich> One immediately closes the filedescriptor after the mmap call
Ulrich> if this mmaped region is all that is needed.

Jes> Ok, what about something like this, it makes
Jes> clock_getcpuclokcid() return ENOENT if the itc drifts. I left
Jes> __itc_drift_internal as a global variable as I am not sure
Jes> whether clock_gettime should be change to check it as well before
Jes> allowing a call for CLOCK_PROCESS_CPUTIME_ID.

Jes> I still want to look into supporting the HPET and SN2 RTC at a
Jes> later stage.

2003-12-01  Jes Sorensen  <jes@wildopensource.com>

	* rt/tst-clock.c (do_test): Print message when skipping
	CLOCK_PROCESS_CPUTIME_ID test.
	* sysdeps/unix/sysv/linux/ia64/clock_getcpuclockid.c: New file.
	Provide CLOCK_PROCESS_CPUTIME_ID only if /proc/sal/itc_drift is 0.

--- libc-old/rt/tst-clock.c	6 Jul 2001 04:55:39 -0000	1.3
+++ libc-2.3/rt/tst-clock.c	1 Dec 2003 14:52:07 -0000
@@ -113,6 +113,8 @@
   if (clock_getcpuclockid (0, &cl) == 0)
     /* XXX It's not yet a bug when this fails.  */
     clock_test (cl);
+  else
+	  printf("CPU clock unavailble, skipping test\n");
 
   return result;
 }
--- /dev/null	Wed Dec 31 16:00:00 1969
+++ libc-2.3/sysdeps/unix/sysv/linux/ia64/clock_getcpuclockid.c	Mon Dec  1 06:21:42 2003
@@ -0,0 +1,75 @@
+/* Copyright (C) 2000, 2001, 2003 Free Software Foundation, Inc.
+   This file is part of the GNU C Library.
+
+   The GNU C Library is free software; you can redistribute it and/or
+   modify it under the terms of the GNU Lesser General Public
+   License as published by the Free Software Foundation; either
+   version 2.1 of the License, or (at your option) any later version.
+
+   The GNU C Library is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+   Lesser General Public License for more details.
+
+   You should have received a copy of the GNU Lesser General Public
+   License along with the GNU C Library; if not, write to the Free
+   Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+   02111-1307 USA.  */
+
+#include <errno.h>
+#include <time.h>
+#include <unistd.h>
+#include <sys/stat.h>
+#include <sys/types.h>
+#include <fcntl.h>
+
+int __itc_drift_internal;
+
+int
+clock_getcpuclockid (pid_t pid, clockid_t *clock_id)
+{
+  /* We don't allow any process ID but our own.  */
+  if (pid != 0 && pid != getpid ())
+    return EPERM;
+
+#ifdef CLOCK_PROCESS_CPUTIME_ID
+  {
+    int retval = ENOENT;
+
+    if (__builtin_expect (__itc_drift_internal == 0, 0))
+      {
+	int fd;
+
+	fd = open ("/proc/sal/itc_drift", O_RDONLY);
+	if (__builtin_expect (fd != -1, 1))
+	  {
+	    char buf[16];
+	    ssize_t n;
+	    n = read (fd, buf, sizeof buf);
+	    if (__builtin_expect (n, 1) > 0)
+	      {
+		if (buf[0] != '0')
+		  __itc_drift_internal = 1;
+		else
+		  __itc_drift_internal = -1;
+	      }
+	    close (fd);
+	  }
+	else
+	  __itc_drift_internal = -1;
+      }
+
+    if (__itc_drift_internal != 1)
+      {
+	/* Store the number.  */
+	*clock_id = CLOCK_PROCESS_CPUTIME_ID;
+	retval = 0;
+      }
+
+    return retval;
+  }
+#else
+  /* We don't have a timer for that.  */
+  return ENOENT;
+#endif
+}

Re: ia64 clock_gettime and HP_TIMING

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


> +	    n = read (fd, buf, sizeof buf);
> +	    if (__builtin_expect (n, 1) > 0)
> +	      {
> +		if (buf[0] != '0')
> +		  __itc_drift_internal = 1;
> +		else
> +		  __itc_drift_internal = -1;

All the machines I have looked at (mostly tigers) have "0" in
/proc/sal/itc_drift.  I.e., the machines wouldn't use the itc which
cannot be correct since they all use it now without problems.

- -- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/16q62ijCOnn/RHQRAoXHAJ9owgaK0JvRHLZ8oNpOKwjJcQ6sBACgvqGL
4xAmN/mO53C3CyRKYLNhmlQ=
=rjbU
-----END PGP SIGNATURE-----

Re: ia64 clock_gettime and HP_TIMING

[Jes Sorensen]

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

Ulrich> All the machines I have looked at (mostly tigers) have "0" in
Ulrich> /proc/sal/itc_drift.  I.e., the machines wouldn't use the itc
Ulrich> which cannot be correct since they all use it now without
Ulrich> problems.

I just reread the code a couple of times and I think it's correct. The
machines that have the problem will have 1 in /proc/sal/itc_drift,
tigers don't drift so they return 0.

+		if (buf[0] != '0')
+		  __itc_drift_internal = 1;
+		else
+		  __itc_drift_internal = -1;

If the buffer is '1' __itc_drift_internal is set to 1, other values
will make it -1, ie. for the Tiger. Then further down where it checks
the value:

+    if (__itc_drift_internal != 1)
+      {
+	/* Store the number.  */
+	*clock_id = CLOCK_PROCESS_CPUTIME_ID;
+	retval = 0;
+      }

Ie. if its_drift_internal == -1 it will return
CLOCK_PROCESS_CPUTIME_ID and work as expected.

I might be confused so feel free to correct me if I misread it again.

Cheers,
Jes

Re: ia64 clock_gettime and HP_TIMING

[David Mosberger]

>>>>> On 11 Dec 2003 05:43:50 -0500, Jes Sorensen <jes@wildopensource.com> said:

  Jes> I might be confused so feel free to correct me if I misread it
  Jes> again.

I also concluded that the code is _probably_ correct but that it's
exceptionally hard to follow it.  It's full of double negations!
Perhaps that could be improved?

	--david

Re: ia64 clock_gettime and HP_TIMING

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've made the change now.  But I rewrote the new code quite a bit.  Thanks,

- -- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/2NfY2ijCOnn/RHQRAhAEAJ9HjhP2jVBAsZYs2lgeN0qLKtp9iQCfcTyI
yV57I6mjJlADEo+MltuKiSY=
=2kIr
-----END PGP SIGNATURE-----

Re: ia64 clock_gettime and HP_TIMING

[Jes Sorensen]

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

Ulrich> I've made the change now.  But I rewrote the new code quite a
Ulrich> bit.  Thanks,

Thanks, I appreciate it. I'll take a look at the new version.

Cheers,
Jes