Live data from Hacker News

Two frequently used system calls are ~77% slower on AWS EC2

blog.packagecloud.io

21–30 of 101 posts

Re: Two frequently used system calls are ~77% slower on AWS EC2

#21
post #17
post #8

Earlier quoted context omitted.

For time?

Yes, for time too. For one, if you don't need over second precision, they why have some of your servers e.g. ask for the current time thousands of times per second? There are ways to get a soft expiration that don't involve asking for the time.

In case someone is interested in a concrete example, I first learned about caching time by discovering this package in my dependencies: https://hackage.haskell.org/package/auto-update

Its README basically says instead of having every web request result in a call to get current time, it instead creates a green thread that runs every second, updating a mutable pointer that stores the current time.

Re: Two frequently used system calls are ~77% slower on AWS EC2

#22
post #3

So… it's not that the syscalls are slower, it's that the Linux-specific mechanism the Linux kernel uses to bypass having to actually perform these calls does not currently work on Xen (and thus EC2).

Depends on if you're looking at this from userspace or kernelspace. From the latter, you're spot on. From the former, the headline's spot on.

Re: Two frequently used system calls are ~77% slower on AWS EC2

#23

Does anyone have any intuition around how this affects a variety of typical workflows? I imagine that these two syscalls are disproportionally likely to affect benchmarks more than real-world usage. How many times is this syscall happening on a system doing things like serving HTTP, or running batch jobs, or hosting a database, etc?

> hosting a database

this will very likely be calling time related system calls, especially clock_gettime with CLOCK_MONOTONIC.

Re: Two frequently used system calls are ~77% slower on AWS EC2

#24
post #5

Author here, greetings. Anyone who finds this interesting may also enjoy our writeup describing every Linux system call method in detail [1]. [1]: https://blog.packagecloud.io/eng/2016/04/05/the-definitive-g...

I will def check that out. Anyone who find that interesting may also enjoy "The Linux Programming Interface" :D

Re: Two frequently used system calls are ~77% slower on AWS EC2

#26
post #5

Author here, greetings. Anyone who finds this interesting may also enjoy our writeup describing every Linux system call method in detail [1]. [1]: https://blog.packagecloud.io/eng/2016/04/05/the-definitive-g...

Nitpick - `77 percent faster` is not the inverse of `77 percent slower`. The line that says `The results of this microbenchmark show that the vDSO method is about 77% faster` should read `446% faster`.

Re: Two frequently used system calls are ~77% slower on AWS EC2

#27

I prefer the way Solaris solved this problem: 1) first, by eliminating the need for a context switch for libc calls such as gettimeofday(), gethrtime(), etc. (there is no public/supported interface on Solaris for syscalls, so libc would be used) 2) by providing additional, specific interfaces with certain guarantees: https://docs.oracle.com/cd/E53394_01/html/E54766/get-sec-fro... This was accomplished by creating a s…

You just described the old method Linux used that was vulnerable to info leaks iirc and why it now a vDSO

Re: Two frequently used system calls are ~77% slower on AWS EC2

#28

Is this just an EC2 problem, or does it affect any Xen/KVM guest? I ran the test program on a Hyper-V VM running CentOS 7 and got the same result: 100 calls to the gettimeofday syscall. Conversely, I tested a vSphere guest (also running CentOS 7), which didn't call gettimeofday at all.

>Is this just an EC2 problem, or does it affect any Xen/KVM guest?

Looks like it's how the Xen hypervisor works.

Re: Two frequently used system calls are ~77% slower on AWS EC2

#29
For anyone looking at the mentions of KVM "under some circumstances" having the same issue and wondering how to avoid it with KVM: KVM appears to support fast vDSO-based time calls as long as:

- You have a stable hardware TSC (you can check this in /proc/cpuinfo on the host, but all reasonably recent hardware should support this).

- The host has the host-side bits of the KVM pvclock enabled.

As long as you meet those two conditions, KVM should support fast vDSO-based time calls.

Post reply on HN