public inbox for systemtap@sourceware.org
 help / color / mirror / Atom feed
* S390 _stp_gettimeofday_ns()  change
@ 2006-10-09 18:56 David Wilder
  0 siblings, 0 replies; 2+ messages in thread
From: David Wilder @ 2006-10-09 18:56 UTC (permalink / raw)
  To: systemtap

[-- Attachment #1: Type: text/plain, Size: 718 bytes --]

While investigating a possible compiler bug on the s390 affecting  
__stp_estimate_cpufreq(),  I came to the conclusion that this function 
made little sense on the s390.  Both get_cycles() and udelay() use the 
TOD clock.  On the s390 the TOD is always at a known frequency on all 
models.   The following patch to _stp_gettimeofday_ns() simply converts 
get_cycles()'s return value into nanoseconds and it has the side effect 
of avoiding the gcc bug :)

The per-cpu timer values are also not needed on the s390 as all cpus use 
the same TOD clock.  However, I did not remove this code for ease of 
maintenance.
-- 

David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA 
dwilder@us.ibm.com
(503)578-3789


[-- Attachment #2: s390_gtod.patch --]
[-- Type: text/x-patch, Size: 1263 bytes --]

diff --git a/src/runtime/time.c b/src/runtime/time.c
index 058cfe4..fd9c26d 100644
--- a/src/runtime/time.c
+++ b/src/runtime/time.c
@@ -55,6 +55,15 @@ void *stp_time = NULL;
  *
  * FIXME: This not very accurate on Xen kernels!
  */
+#if defined (__s390__) || defined (__s390x__)
+static unsigned int
+__stp_estimate_cpufreq(void)
+{
+	// We don't need to find the cpu freq on s390 as the 
+	// TOD clock is always a fix freq. (see: POO pg 4-36.)
+	return 0;
+}
+#else /* __s390x__ || __s390x__ */
 static unsigned int
 __stp_estimate_cpufreq(void)
 {
@@ -66,6 +75,7 @@ __stp_estimate_cpufreq(void)
     end = get_cycles(); barrier();
     return (beg - 2*mid + end);
 }
+#endif
 
 static void
 __stp_time_timer_callback(unsigned long val)
@@ -230,10 +240,18 @@ _stp_gettimeofday_ns(void)
 
     preempt_enable();
 
+#if defined (__s390__) || defined (__s390x__)
+	// The TOD clock on the s390 (read by get_cycles() ) 
+	// is converted to a nano-second value using the following:
+	// (get_cycles() * 125) >> 7;  
+
+	delta = (delta * 125) >> 7;
+
+#else /* __s390__ || __s390x__ */
     // Verify units:
     //   (D cycles) * (1E6 ns/ms) / (F cycles/ms [kHz]) = ns
     delta *= NSEC_PER_MSEC;
     do_div(delta, freq);
+#endif
     return base + delta;
 }
-

^ permalink raw reply	[flat|nested] 2+ messages in thread

* RE: S390 _stp_gettimeofday_ns()  change
@ 2006-10-09 19:39 Stone, Joshua I
  0 siblings, 0 replies; 2+ messages in thread
From: Stone, Joshua I @ 2006-10-09 19:39 UTC (permalink / raw)
  To: David Wilder; +Cc: systemtap

On Monday, October 09, 2006 12:33 PM, David Wilder wrote:
> While investigating a possible compiler bug on the s390 affecting
> __stp_estimate_cpufreq(),  I came to the conclusion that this function
> made little sense on the s390.  Both get_cycles() and udelay() use the
> TOD clock.  On the s390 the TOD is always at a known frequency on all
> models.   The following patch to _stp_gettimeofday_ns() simply
> converts get_cycles()'s return value into nanoseconds and it has the
> side effect of avoiding the gcc bug :)
> 
> The per-cpu timer values are also not needed on the s390 as all cpus
> use the same TOD clock.  However, I did not remove this code for ease
> of maintenance.

Committed.  I don't have an s390 to test, so I'll have to assume you
know what you're talking about. ;)

Josh

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2006-10-09 19:39 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-10-09 18:56 S390 _stp_gettimeofday_ns() change David Wilder
2006-10-09 19:39 Stone, Joshua I

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).