Re: VDSO gettimeofday() x86_64 linux 3.2

From: wilson self
Date: Tue Oct 16 2012 - 15:33:24 EST


current_clocksource is tsc.

the entire source of the test application:
---
#include <stdio.h>
#include <stdlib.h>
#include <sys/time.h>
#include <time.h>

int main() {
struct timeval tim;
gettimeofday(&tim, NULL);
printf("%.6lf seconds\n", tim.tv_sec+tim.tv_usec/1000000.0);
}
---
nothing fancy going on here.

thanks for the help.

On Tue, Oct 16, 2012 at 2:24 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
> On 10/16/2012 11:09 AM, wilson self wrote:
>> I noticed recently that my get time of day calls are quite a bit
>> slower than I would have expected; and it would see that a likely
>> cause is that they are not going via vdso, but rather a system call.
>>
>> In older kernels there was kernel.vsyscall64 parameter to enable them,
>> but this seems to be gone in later kernel releases. What config
>> option or parameter might I be missing that could cause gettimeofday()
>> to use the fallback methods?
>
> That option is gone because it's treated as unconditionally true. What
> does /sys/devices/system/clocksource/clocksource0/current_clocksource
> say? The usual cause of this problem is a clocksource other than tsc or
> hpet. hpet is amazingly slow, though, and arguably the hpet vdso code
> could be deleted because the syscall overhead is the least of your
> worries if you're using the hpet for timing.
>
> (Also, if you're doing the call yourself instead of using libc, make
> sure you're using the vdso and not the old vsyscall. The vsyscall (call
> direct to 0xffffffffff600000) is the slowest possible way to read the
> time -- it's several times slower than the syscall on my box. This is
> mostly intentional.
>
> --Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/