On Sat, 8 Jul 2017, [email protected] 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.
_______________________________________________
systemd-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
