Fast vs slow syscalls (Re: Fwd: [RFC] Kernel shared variables)

[Konstantin Belousov]

On Thu, Jun 07, 2012 at 10:26:10AM +0200, Dag-Erling Sm??rgrav wrote:
> Bruce Evans <brde at optusnet.com.au> writes:
> > Now 2.44 nsec/call makes sense, but you really should add some volatiles
> > here to ensure that getpid() is not optimized away.
> 
> As you can see from the disassembly I provided, it isn't.
> 
> > SO it loops OK, but we can't see what getpid() does.  It must not be
> > doing much.
> 
> Umm, yes, that's the whole point of this conversation.  Linux's getpid()
> is not a syscall, but a library function that returns a constant from a
> page shared by the kernel.
> 
> > 5.4104 nsec/call for gettimeofday() is impossible if there is any
> > rdtsc() hardware call or much layering.
> 
> It's gettimeofday(0, 0), actually, so it doesn't need to read the clock.
> If I pass a struct timeval as the first argument - so it *does* need to
> read the clock - it's a little bit slower but still faster than an
> actual system call.  Here's another run that demonstrates this - a
> little bit slower than previous runs because I have other processes
> running:
> 
> getpid(): 10,000,000 iterations in 30,377 us
> gettimeofday(0, 0): 10,000,000 iterations in 55,571 us
> gettimeofday(&tv, 0): 10,000,000 iterations in 302,634 us
So this timing seems to be approximately same by the order of magnitude
as the times I get for the patch, around 25 vs. 30ns/per gettimeofday()
call.

Linux seems slower probably due to slower CPU ? Mine is 3.4Ghz, while
des used 3.1Ghz for Linux box.

> kill(pid, 0): 10,000,000 iterations in 1,291,793 us
> 
> I can't test a static build since RHEL6 does not provide a static libc.
> 
> DES
> -- 
> Dag-Erling Sm??rgrav - des at des.no
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20120607/bbd6d95d/attachment.pgp