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

[Dag-Erling Smørgrav]

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
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