* Michael Ellerman <m...@ellerman.id.au> wrote (on 2017-07-20 23:18:26 +1000):
> Santosh Sivaraj <sant...@fossix.org> writes:
>
> > Current vDSO64 implementation does not have support for coarse
> > clocks (CLOCK_MONOTONIC_COARSE, CLOCK_REALTIME_COARSE), for which it falls
> > back to system call. Below is a benchmark of the difference in execution
> > time with and without vDSO support.
>
> Hi Santosh,
>
> Great patch! Always good to see asm replaced with C.
>
> > diff --git a/arch/powerpc/kernel/vdso64/gettime.c
> > b/arch/powerpc/kernel/vdso64/gettime.c
> > new file mode 100644
> > index 0000000..01f411f
> > --- /dev/null
> > +++ b/arch/powerpc/kernel/vdso64/gettime.c
> > @@ -0,0 +1,162 @@
> ...
> > +static notrace int gettime_syscall_fallback(clockid_t clk_id,
> > + struct timespec *tp)
> > +{
> > + register clockid_t id asm("r3") = clk_id;
> > + register struct timespec *t asm("r4") = tp;
> > + register int nr asm("r0") = __NR_clock_gettime;
> > + register int ret asm("r3");
>
> I guess this works. I've always been a bit nervous about register
> variables TBH.
Yes, this works. It falls back to syscall in the case of CLOCK_BOOTTIME.
>
> > + asm volatile("sc"
> > + : "=r" (ret)
> > + : "r"(nr), "r"(id), "r"(t)
> > + : "memory");
>
> Not sure we need the memory clobber?
>
> It can clobber more registers than that though.
>
> See: Documentation/powerpc/syscall64-abi.txt
>
> > diff --git a/arch/powerpc/kernel/vdso64/gettimeofday.S
> > b/arch/powerpc/kernel/vdso64/gettimeofday.S
> > index 3820213..1258009 100644
> > --- a/arch/powerpc/kernel/vdso64/gettimeofday.S
> > +++ b/arch/powerpc/kernel/vdso64/gettimeofday.S
> > @@ -51,85 +53,21 @@ V_FUNCTION_BEGIN(__kernel_gettimeofday)
> ...
> > + stwu r1,-112(r1)
> > + .cfi_register lr,r6
> > + std r6,24(r1)
> > + bl V_LOCAL_FUNC(kernel_clock_gettime)
> > crclr cr0*4+so
>
> Clearing CR0[SO] says that the syscall always succeeded.
>
> What happens if you call this with a completely bogus clock id?
>
In case of a bogus clock id, the default case sets 'ret' to -1, which forces it
to fallback to the syscall.
> I think the solution is probably to do the syscall fallback in asm, and
> everything else in C.
Ok. That's what Sergey also sugested. I will send a v2.
Thanks,
Santosh
>
> cheers
--
