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

[Lennart Poettering]

On Fri, 07.07.17 14:35, vcaputo at pengaru.com (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
> 
> Unsure where I stand on core system software assuming certain syscalls are
> always going to be exceptionally cheap though...

Hmm, we generally assume that a couple of syscalls are indeed very
cheap. That's getpid(), getuid() as well as the various ways to get
the system time.

Yes, glibc caching of the PID is very annoying in some cases (as it
complicates code that invokes clone() through a direct syscall
invocation), but still, I think it should be OK assume that it is
cheap to invoke it.

Lennart

-- 
Lennart Poettering, Red Hat