fix(profiling): remove slow getpid call from memalloc path [backport 2.18] #11849
+65
−13
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Backport 6bfe77e from #11848 to 2.18.
memalloc uses getpid to detect whether the process has forked, so that
we can unlock the memalloc lock in the child process (if it isn't
already locked). Unfortunately the getpid call is quite slow. From the
man page: "calls to getpid() always invoke the actual system call,
rather than returning a cached value." Furthermore, we always attempt
to take the lock for allocations, even if we aren't going to sample
them. So this is basically adding a syscall to every allocation.
Move this logic out of the allocation path. Switch to using
pthread_atfork handlers to ensure that the lock is held prior to
forking, and unlock it in the parent and child after forking. This
(maybe) has the added benefit of making sure the data structures are in
a consistent state in the child process after forking. Unclear if that's
an issue prior to this change, though. I may be missing some code that
resets the profiler on fork anyway?
Checklist
Reviewer Checklist