Re: clone() <-> getpid() bug in 2.6?

[Linus Torvalds <torvalds@osdl.org>]

On Sat, 5 Jun 2004, Robert Love wrote:
> 
> It is almost certainly done to improve the speed of some stupid
> microbenchmark - say, one that just calls getpid() repeatedly (simple
> because it is NOT slow) to measure system call overhead.

getpid() is only used in bad benchmarks these days, exactly because 
caching of "pid" has been done for a long time. Every single microkernel 
OS ever built did it, I think.

So yes, you'll find some broken benchmarks using getpid(), but nobody sane 
would take those benchmarks seriously anyway. If you want _real_ system 
call performance measurements, use something like lmbench, which does:

 - getppid() - same cost as getpid(), except you can't just cache the
   results on any POSIX OS (well, you could, but it's more complex:
   you end up having to map the uarea-equvalent into user space or have 
   some notifier for the parent dying).
 - read/write: a hell of a lot more important than the simple system calls 
   anyway.
 - open/close/stat/fstat: very common system calls with interesting 
   performance issues.

That gives you some _real_ data.

> Or maybe libc uses the PID a lot internally.  I don't know.

I think some threading libraries historically used hashes of the
thread-specific pid to look up the thread-specific data. But since glibc
shows the same pid for all regular threads, and gets the pid wrong for
other threads, that's clearly _not_ a valid reason for caching it either.

		Linus