Issue #19443 has been updated by ko1 (Koichi Sasada). byroot (Jean Boussier) wrote in #note-9:
How to read comment #7 results?
It's a flat reduction on our latency (server response time) metrics.
On average, with the pid_cache shim, our server response time is 2 milliseconds faster.
Thank you. BTW it is easy to understand how 2ms has impact or not by showing the measured values of before/after. Anyway, I agree that is valuable improvements. Anonymous wrote in #note-10:
With modern CPU vulnerability mitigations, all system calls got more expensive. Perhaps Linux vDSO mechanism can be extended to support getpid as it does gettimeofday/clock_gettime
I see, especially on virtualization techniques. ---------------------------------------- Feature #19443: Cache `Process.pid` https://bugs.ruby-lang.org/issues/19443#change-102125 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- It's not uncommon for database client and similar network libraries to protect themselves from Process.fork by regularly checking Process.pid Until recently most libc would cache `getpid()` so this was a cheap check to make. However as of glibc version 2.25 the PID cache is removed and calls to `getpid()` always invoke the actual system call which significantly degrades the performance of existing applications. The reason glibc removed the cache is that some libraries were bypassing `fork(2)` by issuing system calls themselves, causing stale cache issues. That isn't a concern for Ruby as bypassing MRI's primitive for forking would render the VM unusable, so we can safely cache the PID. An example of the issue: https://github.com/rails/rails/issues/47418 Patch: https://github.com/ruby/ruby/pull/7326 -- https://bugs.ruby-lang.org/