Date: Mon, 11 Jun 2012 09:56:54 +0100 (BST) From: Robert Watson <rwatson@freeBSd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: arch@freebsd.org Subject: Re: Fast gettimeofday(2) and clock_gettime(2) Message-ID: <alpine.BSF.2.00.1206110952570.78881@fledge.watson.org> In-Reply-To: <20120606165115.GQ85127@deviant.kiev.zoral.com.ua> References: <20120606165115.GQ85127@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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 to
support it not just for native ABI and perhaps 32-bit compat ABIs, but also
the Linux ABI, alternative userspace ABIs (vis o32 on an n64 MIPS kernel),
and so on.
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.
3) For the purposes of adaptive mutexes in userspace, it really would be quite
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 mechanism
for that purpose as well. I guess for now, at least, you're using a single
global page, but in the future, per-process pages might be quite
beneficial.
Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1206110952570.78881>