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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
