Messages in this thread | | | Date | Sat, 5 Jun 2004 16:01:10 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: clone() <-> getpid() bug in 2.6? |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |