Fwd: [RFC] Kernel shared variables

[Gleb Kurtsou]

On (05/06/2012 12:22), John Baldwin wrote:
> On Tuesday, June 05, 2012 11:44:37 am Dag-Erling Smørgrav wrote:
> > John Baldwin <jhb at freebsd.org> writes:
> > > So you call getpid() on each access to a shared resource?
> > 
> > I don't, but I've seen code that does, under the assumption that all the
> > world is Linux and getpid() is free.  Here's a sample from RHEL6 on a
> > 3.1 GHz i5, using raise(0) as a baseline:
> > 
> > getpid(): 10,000,000 iterations in 24,400 ms
> > gettimeofday(0, 0): 10,000,000 iterations in 54,104 ms
> > raise(0): 10,000,000 iterations in 1,284,593 ms
> > 
> > The difference between the first two is due to the fact that while
> > getpid() just returns a constant, gettimeofday(0, 0) performs two
> > comparisons first.  Passing an actual struct timeval to gettimeofday()
> > slows it down by a factor of about 6.
> > 
> > (strace confirms that no system calls occur for either getpid() or
> > gettimeofday(0, 0))
> > 
> > Here is the same program running on FreeBSD 9.0-RELEASE in VirtualBox on
> > an otherwise idle 3.4 GHz i7:
> > 
> > getpid(): 10,000,000 iterations in 777,251 ms
> > gettimeofday(0, 0): 10,000,000 iterations in 799,808 ms
> > raise(0): 10,000,000 iterations in 2,142,275 ms
> 
> Yes, we know getpid() is slow, I think the question is does it matter that 
> it's slow in something other than a microbenchmark.  Can you name the 
> application that you've seen use getpid()?
> 

arc4random* calls getpid() on every invocation (which is right thing to
do, imo) to reinitialize generator after fork.

As an example consider network daemon encrypting/decrypting packets that
is likely to need randomness to encrypt or process considerable portion
of data. Too much depends on the crypto protocols/algorithms used, but
scenario is pretty much real-life. It's a good example when getpid() is
actually needed, but not called often because of being cheap.

Thanks,
Gleb.