Hi Paul,
On PPC, I see a disparity between clock_getres implementations in the
vdso and syscall. I am using a IBM Openpower hardware and 2.6.24 kernel
with CONFIG_HIGH_RES_TIMERS=y.
clock_getres call for CLOCK_REALTIME returns 1 millisecond. However,
when I edit arch/powerpc/kernel/vdso*/gettimeofday.S to force it to use
sys_clock_getres, I get 1 nanosecond resolution. The code in vdso seems
to be returning some pre-defined (incorrect) variables.
Could you please let me know the reason for this? Is it something that
should be fixed in vdso?
Thanks,
Sripathi.
On Sun, Jan 27, 2008 at 07:32:59PM +0530, Sripathi Kodi wrote:
> Hi Paul,
>
> On PPC, I see a disparity between clock_getres implementations in the
> vdso and syscall. I am using a IBM Openpower hardware and 2.6.24 kernel
> with CONFIG_HIGH_RES_TIMERS=y.
>
> clock_getres call for CLOCK_REALTIME returns 1 millisecond. However,
> when I edit arch/powerpc/kernel/vdso*/gettimeofday.S to force it to use
> sys_clock_getres, I get 1 nanosecond resolution. The code in vdso seems
> to be returning some pre-defined (incorrect) variables.
>
> Could you please let me know the reason for this? Is it something that
> should be fixed in vdso?
Almost certainly It's something I missed when I enabled highres timers
on powerpc.
I'll fix this tomorrow.
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
On Sun, Jan 27, 2008 at 07:32:59PM +0530, Sripathi Kodi wrote:
> Hi Paul,
>
> On PPC, I see a disparity between clock_getres implementations in the
> vdso and syscall. I am using a IBM Openpower hardware and 2.6.24 kernel
> with CONFIG_HIGH_RES_TIMERS=y.
>
> clock_getres call for CLOCK_REALTIME returns 1 millisecond. However,
> when I edit arch/powerpc/kernel/vdso*/gettimeofday.S to force it to use
> sys_clock_getres, I get 1 nanosecond resolution. The code in vdso seems
> to be returning some pre-defined (incorrect) variables.
>
> Could you please let me know the reason for this? Is it something that
> should be fixed in vdso?
Can you try the attached patch and see it if works for you?
From: Tony Breeds <[email protected]>
Subject: [PATCH] [POWERPC] Use a sensible default for clock_getres() in the vdso.
This ensures that the syscall and the (fast) vdso versions of clock_getres()
will return the same resolution.
Signed-off-by: Tony Breeds <[email protected]>
---
arch/powerpc/kernel/asm-offsets.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index ed083fe..e6e4928 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -22,6 +22,7 @@
#include <linux/mman.h>
#include <linux/mm.h>
#include <linux/suspend.h>
+#include <linux/hrtimer.h>
#ifdef CONFIG_PPC64
#include <linux/time.h>
#include <linux/hardirq.h>
@@ -312,7 +313,7 @@ int main(void)
DEFINE(CLOCK_REALTIME, CLOCK_REALTIME);
DEFINE(CLOCK_MONOTONIC, CLOCK_MONOTONIC);
DEFINE(NSEC_PER_SEC, NSEC_PER_SEC);
- DEFINE(CLOCK_REALTIME_RES, TICK_NSEC);
+ DEFINE(CLOCK_REALTIME_RES, (KTIME_MONOTONIC_RES).tv64);
#ifdef CONFIG_BUG
DEFINE(BUG_ENTRY_SIZE, sizeof(struct bug_entry));
--
1.5.4
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
* Tony Breeds <[email protected]> [2008-02-05 16:16:48]:
> On Sun, Jan 27, 2008 at 07:32:59PM +0530, Sripathi Kodi wrote:
> > Hi Paul,
> >
> > On PPC, I see a disparity between clock_getres implementations in the
> > vdso and syscall. I am using a IBM Openpower hardware and 2.6.24 kernel
> > with CONFIG_HIGH_RES_TIMERS=y.
> >
> > clock_getres call for CLOCK_REALTIME returns 1 millisecond. However,
> > when I edit arch/powerpc/kernel/vdso*/gettimeofday.S to force it to use
> > sys_clock_getres, I get 1 nanosecond resolution. The code in vdso seems
> > to be returning some pre-defined (incorrect) variables.
> >
> > Could you please let me know the reason for this? Is it something that
> > should be fixed in vdso?
>
> Can you try the attached patch and see it if works for you?
I tried this patch.
It seems to solve the reported problem and give a 1ns resolution.
Thanks.
--
Cheers,
Chirag Jog