From: Stefani Seibold <stefani@seibold.net>
To: Andy Lutomirski <luto@amacapital.net>
Cc: linux-kernel@vger.kernel.org, ak@linux.intel.com,
aarcange@redhat.com, john.stultz@linaro.org
Subject: Re: [PATCH] Add VDSO time function support for x86 32-bit kernel
Date: Tue, 11 Dec 2012 21:40:15 +0100 [thread overview]
Message-ID: <1355258415.30831.2.camel@wall-e> (raw)
In-Reply-To: <CALCETrWDkA8Xkp==okP8xERRSM8tcryRDr_+2RYcSK=vSQV9kQ@mail.gmail.com>
Am Dienstag, den 11.12.2012, 11:37 -0800 schrieb Andy Lutomirski:
> On Tue, Dec 11, 2012 at 8: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.
> >
> > 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.
> >
> > The helper library to use the VDSO functions can be download at
> > http://http://seibold.net/vdso.c
>
> Wow -- another implementation. See Documentation/vDSO/parse_vdso.c.
> (Also, I think your code will break if anyone ever strips the vdso.)
>
> > --- 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
> > }
>
> Is 0xf0 not equal to HPET_COUNTER?
>
Yes, but HPET_COUNTER is more readable.
> >
> > 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;
> > }
>
> __kernel_vsyscall is probably much faster if you can figure out how to
> call it from here :)
>
Yes i know. Thats one of my problems, because i cannot call
__kernel_vsyscall directly due the relocation. Any idea?
> >
> > @@ -74,15 +83,20 @@ notrace static long vdso_fallback_gtod(struct timeval *tv, struct timezone *tz)
> > {
> > long ret;
> >
> > +#ifdef CONFIG_X86_64
> > asm("syscall" : "=a" (ret) :
> > "0" (__NR_gettimeofday), "D" (tv), "S" (tz) : "memory");
> > +#else
> > + asm("int $0x80" : "=a" (ret) :
> > + "a" (__NR_gettimeofday), "b" (tv), "c" (tz) : "memory");
> > +#endif
> > return ret;
> > }
> >
>
> Ditto.
>
> > --- a/arch/x86/vdso/vdso32/vdso32.lds.S
> > +++ b/arch/x86/vdso/vdso32/vdso32.lds.S
> > @@ -24,6 +24,16 @@ VERSION
> > __kernel_vsyscall;
> > __kernel_sigreturn;
> > __kernel_rt_sigreturn;
> > +#ifdef CONFIG_X86_32
> > + clock_gettime;
> > + __vdso_clock_gettime;
> > + gettimeofday;
> > + __vdso_gettimeofday;
> > + gettimeofday;
> > + __vdso_gettimeofday;
> > + time;
> > + __vdso_time;
> > +#endif
>
> Please remove the non-__vdso versions. They're not useful and x86-64
> only has them for backwards compatibility.
>
> > local: *;
> > };
> > }
> > @@ -35,3 +45,8 @@ VDSO32_PRELINK = VDSO_PRELINK;
> > VDSO32_vsyscall = __kernel_vsyscall;
> > VDSO32_sigreturn = __kernel_sigreturn;
> > VDSO32_rt_sigreturn = __kernel_rt_sigreturn;
> > +#ifdef CONFIG_X86_32
> > +VDSO32_clock_gettime = clock_gettime;
> > +VDSO32_gettimeofday = gettimeofday;
> > +VDSO32_time = time;
> > +#endif
>
> Yikes. What's this? (Just curious.)
I don't know if anyone needs this. Maybe i can kick it away.
next prev parent reply other threads:[~2012-12-11 20:41 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
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 [this message]
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=1355258415.30831.2.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 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 NNTP newsgroup(s).