On Fri, Jul 07, 2017 at 03:54:09PM -0700, vcap...@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, vcap...@pengaru.com wrote: > > > On Fri, Jul 07, 2017 at 01:49:54PM -0700, vcap...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel