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

[Zbigniew Jędrzejewski-Szmek]

On Fri, Jul 07, 2017 at 03:54:09PM -0700, vcaputo at pengaru.com wrote:
> On Fri, Jul 07, 2017 at 10:34:22PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > On Fri, Jul 07, 2017 at 02:35:16PM -0700, vcaputo at pengaru.com wrote:
> > > On Fri, Jul 07, 2017 at 01:49:54PM -0700, vcaputo at pengaru.com wrote:
> > > > On Fri, Jul 07, 2017 at 08:37:08PM +0000, Mantas Mikulėnas wrote:
> > > > > Back when that commit was made, didn't glibc cache the getpid() result in
> > > > > userspace? That would explain why it was not noticed.
> > > >
> > > > Hmm, this crossed my mind, and come to think of it I did a dist-upgrade
> > > > from Debian jessie to stretch overnight machine and haven't rebooted.
> > > > 
> > > > Perhaps the vdso isn't working and the costly getpid() is a red herring, will
> > > > reboot and retest to confirm.
> > > > 
> > > 
> > > It appears Debian has a glibc patch to disable the caching (I was unaware
> > > such an elaborate dance was being performed to cache this!)
> > > 
> > > https://anonscm.debian.org/cgit/pkg-glibc/glibc.git/commit/debian/patches/any?id=5850253f509604dd46a6131acc057ea26e1588ba
> > 
> > Do we know the justification for this patch?
> > 
> 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857909
> 
> Which references this upstream glibc bug:
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=19957
> https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commit;h=0cb313f7cb0e418b3d56f3a2ac69790522ab825d
> 
> 
> > > Unsure where I stand on core system software assuming certain syscalls are
> > > always going to be exceptionally cheap though...
> > 
> > Optimization is never in a vacuum. If glibc does something cheaply, it
> > seems reasonable to take advantage of it.
> > 
> 
> Except there's always a risk of these things regressing to normal syscalls,
> and one has to weigh the utility against that.  It's unclear to me what
> significant utility having the sd-journal API police changing pids by
> calling getpid() at every public entrypoint is bringing to the table.

So it seems the issue has been fixed in glibc upstream more than a year
ago, and it doesn't seem to make sense to optimize current systemd git for
that.

I see the argument that the getpid() checks are a bit excessive. Is their
overhead actually noticeable with current glibc?

Zbyszek