3 ms·

The author writes: "Reduce the number of syscalls by caching the value of gettimeofday() until a new tick happens or network packet comes in" But I'm pretty sur

The author writes: "Reduce the number of syscalls by caching the value of gettimeofday() until a new tick happens or network packet comes in" But I'm pretty sure glibc on recent Linux handles gettimeofday in user-space, without context switch (kernel maps the data to userspace). I guess caching the value locally and updating it 1/sec or something would still help if there are thousands of calls/sec, but not as much as if it was really a syscall.

def- 10y ago
You're right. Unfortunately with virtual machines that doesn't always work. You can enable it manually but that's more inefficient because the Kernel can't use paravirtualization for clock then. I stumbled upon this a month ago: https://ddnet.tw/irclogs/2016-05-17.log https://ddnet.tw/irclogs/2016-05-17.log 21:37 <@deen> A third of the sys calls of a DDNet server are recfrom and sendto each 21:37 <@deen> they always occur in large chunks, so ideal for sendmmsg/recvmmsg 21:38 <@deen> the last third are mostly strange time and gettimeofday calls, I thought I got rid of most of them 21:40 <@deen> server with 30 players causes 3000 syscalls a second 22:00 <@deen> PACKET_MMAP is very cool, reading packets with 0 syscalls, too bad it's not for regular applications (requires root, doesn't work with normal udp socket): https://www.kernel.org/doc/Documentation/networking/packet_mmap.txt 22:04 <@deen> and then the glibc version matters a lot for syscalls. new versions of glibc don't syscall at all for gettimeofday 22:05 <@deen> (or something else is causing that, not sure yet) 22:13 <@deen> Reading the glibc implementation, that's done by vDSO, interesting: http://man7.org/linux/man-pages/man7/vdso.7.html 22:32 <@deen> totally confused why some of our servers use vdso gettimeofday, others not even though they have more recent kernel and glibc 22:41 <@deen> ok, probably depends on the underlying clock that the vps uses. pvclock is used with kvm and doesn't support vdso. but looks like there's some progress being made: https://lkml.org/lkml/2015/12/9/914

def- 10y ago

You're right. Unfortunately with virtual machines that doesn't always work. You can enable it manually but that's more inefficient because the Kernel can't use paravirtualization for clock then. I stumbled upon this a month ago: https://ddnet.tw/irclogs/2016-05-17.log https://ddnet.tw/irclogs/2016-05-17.log 21:37 <@deen> A third of the sys calls of a DDNet server are recfrom and sendto each 21:37 <@deen> they always occur in large chunks, so ideal for sendmmsg/recvmmsg 21:38 <@deen> the last third are mostly strange time and gettimeofday calls, I thought I got rid of most of them 21:40 <@deen> server with 30 players causes 3000 syscalls a second 22:00 <@deen> PACKET_MMAP is very cool, reading packets with 0 syscalls, too bad it's not for regular applications (requires root, doesn't work with normal udp socket): https://www.kernel.org/doc/Documentation/networking/packet_mmap.txt 22:04 <@deen> and then the glibc version matters a lot for syscalls. new versions of glibc don't syscall at all for gettimeofday 22:05 <@deen> (or something else is causing that, not sure yet) 22:13 <@deen> Reading the glibc implementation, that's done by vDSO, interesting: http://man7.org/linux/man-pages/man7/vdso.7.html 22:32 <@deen> totally confused why some of our servers use vdso gettimeofday, others not even though they have more recent kernel and glibc 22:41 <@deen> ok, probably depends on the underlying clock that the vps uses. pvclock is used with kvm and doesn't support vdso. but looks like there's some progress being made: https://lkml.org/lkml/2015/12/9/914