gettimeofday() -- user-space vs. system call [LWN.net]

gettimeofday() -- user-space vs. system call

Posted Feb 6, 2007 20:06 UTC (Tue) by AnswerGuy (guest, #1256)
In reply to: Methodology used by pjm
Parent article: Comparing Linux and Minix

While gettimeofday() should be one of the simplest system calls in the
universe (and uname() should be another) ... it's even better if you
have a kernel that implemeents these as pre-initialized data mappings
into every process' address space.

Then the libc can just fetch the relevant data from its own address
space and incur no context switch overhead.

This is, of course, a standard memory for speed trade-off. Tridge (of
Samba fame) once described to me a case on some system where he tweaked
a kernel and libc in this way and saw a significant performance improvement
(some Fujitsu hardware?).

(Of course it's possible that the effect would be less dramatic on x86
hardware running Linux --- but it's still an option to consider. If we
did it then I imagine it would be a bit like the VDSO mapping the kernel
is already doing for the latest TLS support. The system call would still
exist for legacy support ... but newer libc updates would check for and
use the extra data area for return such data. (The time of day and
perhaps some other dynamic system-wide information would all be stored
in one or two read-only pages which would be aliased into every user
address space be default ... while process-state info would be mapped
into private pages. Obviously some accomodation for the virtualization
models would have to be made --- so each virtual kernel would have it's
own pages to map into process).

JimD

(Log in to post comments)

gettimeofday() -- user-space vs. system call

Posted Feb 7, 2007 9:26 UTC (Wed) by ekj (subscriber, #1524) [Link]

The balance tends to shift over time too.

The amount of memory available increases a lot more than the available syscalls do. In other words, putting the data that gettimeofday() needs into the address-space of every process costs just as many bytes now as it always did (well, modulus avg number of processess on a box), but the available memory increases exponentially.

Lots of stuff may make sense on a 16GB machine which doesn't make sense on a 4MB machine. If you do enough such trickery that you'd have wasted half the RAM of the 4MB machine you'll have wasted 0.01% of the memory of the large machine. If you assume the large machine has 10 times as many processes, you've still only wasted 0.1% of the available memory.

This is even more true for space/performance tradeoffs that are internal to the kernel only. Back when Linux was new, wasting 1MB to double in-kernel performance would've been ridicolous. Today it's equally obvious that it'd be a huge win in most scenarios.

Gets complicated though, because larger structures tend to hurt cache-hit ratio, and main-memory is *SLOW* compared to on-die-cache.

gettimeofday() -- user-space vs. system call

Posted Feb 7, 2007 16:53 UTC (Wed) by nix (subscriber, #2304) [Link]

You don't need any libc support for this (other than the existing vsyscall support). The code on the vsyscall page which normally runs SYSENTER could spot that the syscall being invoked is gettimeofday() and copy out the appropriate value from elsewhere in the vsyscall page without ever transitioning to kernel mode. (A patch of this nature was discussed a few years ago, but I'm not sure if any code resulted.)

gettimeofday() -- user-space vs. system call

Posted Aug 23, 2010 13:09 UTC (Mon) by Blaisorblade (guest, #25465) [Link]

The mechanism you describe is only valid for i386.
That mechanism is used on x86_64, for one - see arch/x86/kernel/vsyscall_64.c:vgettimeofday and/or arch/x86/vdso/vclock_gettime.c (two different reimplementations of the same concept).

However, the existing implementation for x86_64 requires libc support, and no implementation of this for x86_32 exists. Dunno why.
The only difference I seem to see is that on i386 there is no support for int 0x80 calls, so probably libc uses syscall/sysenter directly.