Fast gettimeofday(2) and clock_gettime(2)
David Xu
listlog2011 at gmail.com
Tue Jun 12 01:52:53 UTC 2012
On 2012/6/11 16:56, 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
> 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.
>
Solaris uses per-thread page shared between kernel and userland, their
schedctl()
interface is designed for this purpose, not only you can know if a
thread is running,
but also userland can tell kernel to not preempt the current thread
while is in
critical section, for example, it is doing adaptive spin, set a
no_preempt bit to let
kernel delay for a few of ticks before it preempts the thread immediately.
I even have an earlier patch:
http://people.freebsd.org/~davidxu/schedctl/
<http://people.freebsd.org/%7Edavidxu/schedctl/>
However I don't know if you can get real-world advantage if you really
implemented
this feature because this might increase cache-line sharing.
> Robert
More information about the freebsd-arch
mailing list