Fast gettimeofday(2) and clock_gettime(2)
kostikbel at gmail.com
Mon Jun 11 09:18:17 UTC 2012
On Mon, Jun 11, 2012 at 09:56:54AM +0100, Robert Watson wrote:
> On Wed, 6 Jun 2012, Konstantin Belousov wrote:
> >The whole struct vdso_timekeep is versioned, as well as individual struct
> >vdso_timehands, which should allow to implement future algorithms without
> >breaking binary compatibility. The code is structured to eventually move
> >__vdso_* functions out of libc into VDSO, if it ever materialize. This
> >desire explains vdso prefix and header file names.
> >I implemented and tested the userspace timecounter on amd64, both for 64
> >and 32 bit binaries, it would probably work for i386 too. Other
> >architecture maintainers are welcome to add neccessary support there. You
> >need to provide machine/vdso.h header with definitions of
> >VDSO_TIMEHANDS_MD fields for struct vdso_timehands, which should provide
> >information for userspace to implement fast tc_get_timecount(). The fields
> >are filled in per-arch cpu_fill_vdso_timehands(9) function. If your
> >architecture support 32bit compat, there are cpu_fill_vdso_timehands32(9)
> >and VDSO_TIMEHANDS_MD32 to code as well. After that, the
> >lib/libc/<arch>/sys/__vdso_gettc.c should contain an implemention of
> >__vdso_gettc() function, exact analogue of tc_get_timecount().
> Hi Kostik:
> I'm glad to see someone is finally grappling with this issue. I could
From the real-world tests, it seems that e.g. mysql does not notice any
difference with the faster (4-7x) gettimeofday() and clock_gettime()
> never entirely decide how I felt about the Linux VSDO mechanism, but having
> some solution here is actually quite important. A few thoughts that you
> might comment on:
> 1) It would be nice if we linked any (future) notion of VDSO to the same
> mechanism we use for ELF branding/ABI emulation -- you conceivably want
> support it not just for native ABI and perhaps 32-bit compat ABIs, but
> the Linux ABI, alternative userspace ABIs (vis o32 on an n64 MIPS
> and so on.
This is solved almost automatically with any sensible VDSO
implementation, since VDSO _must_ be per-ABI. You simply cannot use
amd64 VDSO in 32bit process. Please note that even the current shared
page mechanism is already per-ABI, since it is attached to struct
sysentvec instance. It just so happen that I found convenient and less
resoirce-wasteful to reuse the same page for both 32bit and 64bit on
amd64. For VDSO, it definitely should be separated (which is trivial).
VDSO for Linux is required to have Linux/amd64 emulator running. At least
I was told so by Chagin.
> 2) Once the VDSO mechanism is there, you get into feature creep space, and
> looking at how Linux handles pluggable system call mechanisms for the C
> library is actually interesting.
Yes, there is a possibility. But really I think that we should left i386
on the pasture. Do we really care about 0.5% (?) of the speed for 32 bit
Main benefits from VDSO is due to improved toolchain support (dwarf
unwinding for signal trampolines) and specific operation optimizations,
like gettimeofday(), which is performed without the need to keep
kernel ABI intact, IMO.
As an example, I saw that Linux could export HPET registers page r/o on
machines where rdtsc is unusable. Due to VDSO, this is transparent to
libc. I preferred not to port HPET timers into usermode for now exactly
because libc should become aware of them.
> 3) For the purposes of adaptive mutexes in userspace, it really would be
> nice to know whether remote threads are running or not, in the same way
> that cheap access to remote thread run state in the kernel makes for much
> more efficient adaptive spinning. I wonder if we could use this
> for that purpose as well. I guess for now, at least, you're using a
> global page, but in the future, per-process pages might be quite
The per-process page looks almost undoable. I think that what could be
made working, although with some hacks, is per-CPU page, and the page
content update on context switch. This could benefit trivial system calls
like getpid(), getppid() and others, but obviously cause increased context
Per-CPU page would then solve the proposal of having an indicator of
other threads running. I am not sure how much do we care of the potential
information leak there.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20120611/935a63e7/attachment.pgp
More information about the freebsd-arch