[systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

[Lennart Poettering]

On Tue, 11.07.17 21:26, Florian Weimer (fw at deneb.enyo.de) wrote:

> * Lennart Poettering:
> 
> > Apparently, this regressed between this version and
> > glibc-2.24-9.fc25.x86_64 hence.
> 
> Yes, I backported the fork cache removal to Fedora 25.  There is no
> longer a good way to main such a cache in userspace because glibc
> cannot intercept anymore all the ways that can change the PID of the
> current process because the kernel interfaces for process management
> are incredibly rich these days.

Please be more specific here. What is this all about? What triggered
this specifically? is this about docker? docker is written in golang
anyway, iirc, which doesn't bother with linking to libc anyway?

Is this a glibc upstream choice primarily? Were the regressions this
causes considered?

I mean, the getpid() checking code is not only in use in systemd, but
in various other bits, in particular PulseAudio, where I started
adding these checks for a good reason. It sounds pretty strange to me
to just regress all that...

Were there considerations to solve this differently? (for example,
expose some concept how getpid() caching can be turned out
specifically for apps needing that? it appears to me that after all
the number of apps calling clone() directly are very much numbered,
while a ton of apps will benefit from getpid() caching...)

Please elaborate!

Lennart

-- 
Lennart Poettering, Red Hat