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

[Michael Chapman]

On Sat, 8 Jul 2017, vcaputo at pengaru.com wrote:
> In doing some casual journalctl profiling and stracing, it became apparent
> that `journalctl -b --no-pager` runs across a significant quantity of logs,
> ~10% of the time was thrown away on getpid() calls due to commmit a65f06b.
>
> As-is:
> # time ./journalctl -b --no-pager > /dev/null
>
> real    0m11.033s
> user    0m10.084s
> sys     0m0.943s
>
>
> After changing journal_pid_changed() to simply return 1:
> # time ./journalctl -b --no-pager > /dev/null
>
>  real    0m9.641s
>  user    0m9.449s
>  sys     0m0.191s

[...]

> As this is public sd-journal API, it's somewhat set in stone.

So it's arguable whether making an API work in _more_ situations than it 
previously did is a "breaking" change.

I've tried to go through the history for the various *_pid_changed() 
functions in the APIs systemd presents, and I'm struggling to find a good 
justification for them. It seems like it was originally added for sd-bus 
in:

   https://github.com/systemd/systemd/commit/d5a2b9a6f455468a0f29483303657ab4fd7013d8

And then other APIs copied it to be consistent with sd-bus:

   https://github.com/systemd/systemd/commit/a65f06bb27688a6738f2f94b7f055f4c66768d63
   https://github.com/systemd/systemd/commit/eaa3cbef3b8c214cd5c2d75b04e70ad477187e17
   https://github.com/systemd/systemd/commit/adf412b9ec7292e0c83aaf9ab93e08c2c8bd524a

Unfortunately none of these commits describe what will go wrong if one of 
these APIs is used across fork. Does anybody know what specifically is the 
problem being addressed here? Can we detect this problem in some other 
way?

My guess is that it has something to do with epoll's boneheaded design, 
which basically requires code to recreate its epoll sets completely after 
a fork. But surely if sd-event is the only thing that uses epoll we can 
just have only it check the PID and let it propagate ECHILD back up to 
those APIs that use it, rather than testing the PID in each and every API 
individually?

>    However,
> there's nothing preventing the systemd-internal tooling from linking with
> a less defensive/conformant underlying implementation shared with the public
> API implementation where these kinds of overheads can be preserved.

This would be useful for external users of these APIs as well.