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

Linus Torvalds
2004-06-05T23:01:28Z

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