All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefani Seibold <stefani@seibold.net>
To: John Stultz <john.stultz@linaro.org>
Cc: linux-kernel@vger.kernel.org, ak@linux.intel.com,
	aarcange@redhat.com, luto@amacapital.net
Subject: Re: [PATCH] Add VDSO time function support for x86 32-bit kernel
Date: Tue, 11 Dec 2012 21:54:19 +0100	[thread overview]
Message-ID: <1355259259.30831.13.camel@wall-e> (raw)
In-Reply-To: <50C78927.6080302@linaro.org>

Am Dienstag, den 11.12.2012, 11:27 -0800 schrieb John Stultz:
> On 12/11/2012 08:11 AM, stefani@seibold.net wrote:
> > From: Stefani Seibold <stefani@seibold.net>
> >
> > This small patch add the functions vdso_gettimeofday(), vdso_clock_gettime()
> > and vdso_time() support to the VDSO for x86 32-bit kernels.
> >
> > The reason to do this was to get a fast reliable time stamp. Many developers
> > uses TSC to get a fast time time stamp, without knowing the pitfalls. VDSO
> > time functions a fast and reliable way, because the kernel knows the best time
> > source and the P- and C-state of the CPU.
> Very cool. There have been similar implementations of this patch over 
> the years, but they were all bit more hackish then this.
> 
Thanks, i think it is not more hackish than the x86 64 code.

> 
> > For x86 the vclock_gettime.c currently supports only the HPET and TSC timer,
> > the ACPI timer should be easily to add with an other patch.
> Although the ACPI PM timer requires port-io which would need tweaking to 
> allow normal users to access it. And I'm not sure if the performance 
> would be much improved, as the port-io probably dominates the 
> performance cost.
> 

It was only an idea. I think it would be easy to give the ioperm read
for the ACPI Timer without breaking anything.

> > The helper library to use the VDSO functions can be download at
> > http://http://seibold.net/vdso.c
> > The libary is very small, only 228 lines of code. Compile it with
> > gcc -Wall -O3 -fpic vdso.c -lrt -shared -o libvdso.so
> > and use it with LD_PRELOAD=<path>/libvdso.so
> >
> > This kind of helper must be integrated into glibc, for x86 64-bit and
> > PowerPC it is already there.
> >
> A few notes below...
> 
> 
> > diff --git a/arch/x86/include/asm/compat.h b/arch/x86/include/asm/compat.h
> > index 59c6c40..45ba688 100644
> > --- a/arch/x86/include/asm/compat.h
> > +++ b/arch/x86/include/asm/compat.h
> > @@ -295,6 +295,10 @@ static inline compat_uptr_t ptr_to_compat(void __user *uptr)
> >   
> >   static inline void __user *arch_compat_alloc_user_space(long len)
> >   {
> > +#ifdef CONFIG_X86_32
> > +	struct pt_regs *regs = task_pt_regs(current);
> > +	return (void __user *)regs->sp - len;
> > +#else
> >   	compat_uptr_t sp;
> >   
> >   	if (test_thread_flag(TIF_IA32)) {
> > @@ -305,6 +309,7 @@ static inline void __user *arch_compat_alloc_user_space(long len)
> >   	}
> >   
> >   	return (void __user *)round_down(sp - len, 16);
> > +#endif
> >   }
> 
> This style of in-line ifdefs are ugly and hard to read.
> 
> So instead of doing:
> void myfunction (void)
> {
> #ifdef 32bits
>      32_bit_implementation();
> #else
>      64_bit_implementation();
> #endif
> }
> 
> Where possible, please do:
> #ifdef 32bits
> void myfunction1(void)
> {
>      32_bit implementation();
> }
> void myfunction2(void)
> {
> ....
> #else /*64 bit versions */
> void myfunction1(void)
> {
>      64_bit implementation();
> }
> void myfunction2(void)
> ....
> #endif
> 
> > diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
> > index 4df6c37..2dc6b72 100644
> > --- a/arch/x86/vdso/vclock_gettime.c
> > +++ b/arch/x86/vdso/vclock_gettime.c
> > @@ -59,14 +59,23 @@ notrace static cycle_t vread_tsc(void)
> >   
> >   static notrace cycle_t vread_hpet(void)
> >   {
> > +#ifdef CONFIG_X86_64
> >   	return readl((const void __iomem *)fix_to_virt(VSYSCALL_HPET) + 0xf0);
> > +#else
> > +	return readl(VVAR(vsyscall_hpet) + HPET_COUNTER);
> > +#endif
> >   }
> >   
> >   notrace static long vdso_fallback_gettime(long clock, struct timespec *ts)
> >   {
> >   	long ret;
> > +#ifdef CONFIG_X86_64
> >   	asm("syscall" : "=a" (ret) :
> >   	    "0" (__NR_clock_gettime),"D" (clock), "S" (ts) : "memory");
> > +#else
> > +	asm("int $0x80" : "=a" (ret) :
> > +	    "a" (__NR_clock_gettime), "b" (clock), "c" (ts) : "memory");
> > +#endif
> >   	return ret;
> >   }
> Same point here.
> 
> 

Will be fixed.

> > diff --git a/arch/x86/vdso/vdso32/vclock_gettime.c b/arch/x86/vdso/vdso32/vclock_gettime.c
> > new file mode 100644
> > index 0000000..c9a1909
> > --- /dev/null
> > +++ b/arch/x86/vdso/vdso32/vclock_gettime.c
> > @@ -0,0 +1,7 @@
> > +/*
> > + * since vgtod layout differs between X86_64 and x86_32, it is not possible to
> > + * provide a 32 bit vclock with a 64 bit kernel
> > + */
> > +#ifdef CONFIG_X86_32
> > +#include "../vclock_gettime.c"
> > +#endif
> Could you expand a bit as to why a compat layer isn't possible? It seems 
> we could easily convert the vsyscall_gtod_data to a more explicit 
> arch-neutral size. Or is it the actual data page mapping?
> 

This could be done in a subsequent patch. First i want not change to
much, to make the review easier. Converting the vsyscall_gtod_data to
arch neutral is not so easy, because the size of time_t, timezone and
timespec differs. So currently 32 bit programs running under a 64 bit
kernel will not get a VDSO with time functions. But real 32 bit kernel
will provide it.



  parent reply	other threads:[~2012-12-11 20:55 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-11 16:11 [PATCH] Add VDSO time function support for x86 32-bit kernel stefani
2012-12-11 19:27 ` John Stultz
2012-12-11 19:37   ` Andy Lutomirski
2012-12-11 20:54   ` Stefani Seibold [this message]
2012-12-11 21:18     ` Andy Lutomirski
2012-12-11 21:28       ` Stefani Seibold
2012-12-11 19:37 ` Andy Lutomirski
2012-12-11 20:40   ` Stefani Seibold
2012-12-12  1:29     ` Andy Lutomirski
  -- strict thread matches above, loose matches on Subject: below --
2012-12-12 20:19 stefani
2012-12-12 23:34 ` H. Peter Anvin
2012-12-13  5:53   ` Stefani Seibold
2012-12-13  6:10     ` H. Peter Anvin
2012-12-13  6:14     ` H. Peter Anvin
2012-12-13  6:17       ` Stefani Seibold
2012-12-13  6:47         ` H. Peter Anvin
2012-12-13  7:17           ` Stefani Seibold
2012-12-13 19:32             ` Andy Lutomirski
2012-12-14  0:09               ` H. Peter Anvin
2012-12-14  0:20                 ` Andy Lutomirski
2012-12-14  0:36                   ` H. Peter Anvin
2012-12-14  1:32                   ` H. Peter Anvin
2012-12-14  1:42                     ` Andy Lutomirski
2012-12-14  1:49                       ` H. Peter Anvin
2012-12-14  2:11                         ` Andy Lutomirski
2012-12-14  2:18                           ` H. Peter Anvin
2012-12-14  2:20                             ` Andy Lutomirski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1355259259.30831.13.camel@wall-e \
    --to=stefani@seibold.net \
    --cc=aarcange@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=john.stultz@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.