This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
[runtime]wrong frequency estimation
- From: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- To: SystemTAP <systemtap at sources dot redhat dot com>
- Cc: Yumiko Sugita <yumiko dot sugita dot yf at hitachi dot com>, Satoshi Oshima <soshima at redhat dot com>, Hideo Aoki <haoki at redhat dot com>, Satoru MORIYA <satoru dot moriya dot br at hitachi dot com>
- Date: Wed, 06 Jun 2007 00:54:44 +0900
- Subject: [runtime]wrong frequency estimation
- Organization: Systems Development Lab., Hitachi, Ltd., Japan
Hi,
I found that __stp_estimate_cpufreq() in runtime/time.c returned inaccurate
cpu frequency, especially on Xen kernel. If frequency is estimated smaller
than true frequency, gettimeofday_*() can rewind.
Thus, I think we better use special methods for each architecture,
e.g. cpufreq_quick_get() and cpu_khz for i386/x86-64 and local_cpu_data->
itc_freq for ia64. If we can't use those methods, estimating frequency by
using udeley() is the last resort.
I attached a patch to do that.
What would you think about this idea?
Best regards,
---
runtime/time.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
Index: systemtap/runtime/time.c
===================================================================
--- systemtap.orig/runtime/time.c 2007-06-05 16:29:19.000000000 +0900
+++ systemtap/runtime/time.c 2007-06-05 19:00:19.000000000 +0900
@@ -65,7 +65,17 @@
// 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__ */
+#elif defined (__i386__) || defined (__x86_64__)
+
+ unsigned int ret;
+ ret = cpufreq_quick_get(smp_processor_id());
+ if (ret == 0)
+ ret = cpu_khz;
+ return ret;
+#elif defined (__ia64__)
+
+ return (local_cpu_data->itc_freq/1000);
+#else
cycles_t beg, mid, end;
beg = get_cycles(); barrier();