On Fri, 07.07.17 14:35, vcap...@pengaru.com (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 > > Unsure where I stand on core system software assuming certain syscalls are > always going to be exceptionally cheap though...
Hmm, we generally assume that a couple of syscalls are indeed very cheap. That's getpid(), getuid() as well as the various ways to get the system time. Yes, glibc caching of the PID is very annoying in some cases (as it complicates code that invokes clone() through a direct syscall invocation), but still, I think it should be OK assume that it is cheap to invoke it. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
