[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [Libevent-users] Strange timeout scheduling in 1.4



On Wed, Jul 27, 2011 at 10:10:36PM +0100, Nicholas Marriott wrote:
> On Wed, Jul 27, 2011 at 01:10:05PM -0700, William Ahern wrote:
<snip>
> > Has anyone tested the performance gain of caching? Linux's gettimeofday()
> > doesn't trap into the kernel; it effectively just reads a shared memory
> > page. IIRC it's something like 100x-1000x faster than gettimeofday() in
> > OpenBSD, which (again, IIRC) reads from the hardware clock every call (Linux
> > usually has an HPET update the clock asynchronously).
<snip>
> AFAIK this optimization in Linux is only available on some architectures
> and there is a knob with several possible settings.
> 
> Without this, gettimeofday() can be quite expensive.

Okay, so I redid my homework. Asynchronous time counters were enabled on
OpenBSD AMD64 for the May 2007 release of 4.1. See
sys/arch/amd64/include/_time.h in the cvsweb repo. I probably did my tests
in Jan 2007, which means I was 4.0 at best.

I grepped through the Linux 3.0 kernel sources. All of the time code for all
the architectures, AFAICT, is based on an asynchronous model as well.

PowerPC, x86, and s390 Linux architectures have vDSO gettimeofday support.
All of the various x86-64 boxes I could find have this enabled by default,
the oldest running a 2009 kernel. None of the x86-32 boxes appeared to do
vDSO as time(1) reported them spending all their time in the kernel.

However, the difference between vDSO support and no vDSO support was nothing
compared to the OpenBSD v. Linux differences. OpenBSD system calls are
incredibly slow compared to Linux. A million gettimeofday calls on OpenBSD
takes 5 seconds to complete, whereas a similarly equipped Linux box
sans-vDSO takes about 0.15 seconds. Time counter support _should_ be enabled
on my OpenBSD box, so that's a 33x difference in syscall performance.

Basically, the cost of gettimeofday() shouldn't be much of a concern to
anybody on Linux. It _shouldn't_ be much of a concern on OpenBSD. If I
understand the kern_tc.c implementation properly, gettimeofday() doesn't do
any writes at all. In fact, OpenBSD appears to have modified the original
FreeBSD Timecounter implementation so that all gettimeofday() and
clock_gettime() calls just read the cached value from the periodic timer.
This would mean that OpenBSD discarded precision entirely. But it would also
mean, I think, that it should be trivial to map the entire timehand ring
buffer into userspace. This wouldn't even require the magical vDSO-type
stuff that Linux does, since it's just the data, and not code, that would be
mapped. Though, I'm not a kernel guy so maybe I've completely missed
something.

***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.