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

[Lennart Poettering]

On Mon, 10.07.17 14:04, vcaputo at pengaru.com (vcaputo at pengaru.com) wrote:

> > > 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.
> > 
> 
> Can you provide a commit id?  I took a glance at sourcewaire.org/git/gitweb.cgi
> for getpid commits and didn't see anything relevant since the removal[1].
> 
> 
> > I see the argument that the getpid() checks are a bit excessive. Is their
> > overhead actually noticeable with current glibc?
> > 
> 
> On my spare arch system I still see gratuitous getpid() calls from
> journalctl, which is on glibc 2.5-2.
> 
> The pollution of strace output alone due to these checks is nuisance enough
> for me to want the checks removed, considering their only value is to catch
> programmer errors.  There's an abundance of potential programmer errors
> we're not making any effort to prevent, why is this one so privileged that
> it warrants policing?

strace doesn't show getpid() calls if they are properly cached. While
stracing journalctl I never have seen a single one of them...

> I appreciate Lennart's point about the hazards of forking from threaded
> programs.  It just doesn't seem like a valid rationalization for sprinkling
> a system library's entrypoints with getpid() calls to catch this in
> production.

Normally it's dead cheap to check that, it's just reading and
comparing one memory location. It's a pitty that this isn't the case
currently on Debian, but as it appears this is an oversight on their
side, and I am sure it will be eventually fixed there, if it hasn't already.

> Considering the associated potential costs, and the historic controversy
> surrounding the caching of this particular syscall[2] I'm a bit confused by
> the status quo.

Well, normally there's next to no cost to this, on pretty much any non-Debian
distro there isn't any price for this to pay...

I mean, we could certainly cache that value in our code too, but given
that glibc does that already in the normal case I think this is better
left to be fixed in glibc rather than our code.

Lennart

-- 
Lennart Poettering, Red Hat