linux-kernel - Re: VDSO gettimeofday() x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAZUjxAPAUD50asniJVNgD3X=vM_d=GPKJ5C2eVGo6r4HUKYLQ@mail.gmail.com>
Date:	Tue, 16 Oct 2012 14:33:30 -0500
From:	wilson self <wself00@...il.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: VDSO gettimeofday() x86_64 linux 3.2

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@...capital.net> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/