3 ms·

Anyone know why getpid/getuid still aren’t implemented as vdso?

by vlovich123 3y ago

tptacek 3y ago
When are you ever calling getuid in a tight loop?
- bitcharmer 3y ago
  GP's question is perfectly valid. It doesn't have to be called within a tight loop at all. It could be a latency sensitive routine for example. I can see at least a few real life applications where it would make sense to have the syscall vDSO'd.
  - tptacek 3y ago
    What's one of them?
    - vlovich123 3y ago
      https://bugzilla.redhat.com/show_bug.cgi?id=1469670 https://bugzilla.redhat.com/show_bug.cgi?id=1469670 I would appreciate if someone explained why it’s not a vdso rather than just repeating it’s not necessary like that’s a sufficient explanation.
      - masklinn 3y ago
        It’s not a VDSO because it was never added as one. “Not a VDSO” is the default, a VDSO is additional complexity and maintenance so you need to justify its addition / existence, not its non-existence. Also given https://ipfs.io/ipfs/QmdA5WkDNALetBn4iFeSepHjdLGJdxPBwZyY47ir1bZGAK/comp/linux/getpid_caching.html https://ipfs.io/ipfs/QmdA5WkDNALetBn4iFeSepHjdLGJdxPBwZyY47i... while Linus may have changed tack in the decades since I would not expect much support from stating getpid is performance critical to you.
      - tptacek 3y ago
        I think we're just talking past each other. I'm asking why you'd want to vDSO getuid(), not getpid(). I can imagine cases where you'd repeatedly be calling getpid().
        vlovich123 3y ago
        Eh. All of these things requiring a context switch seems alien to me. So it’s less of a use case and more “just make it fast” since the incremental cost should be 0?
        loeg 3y ago
        Well, the incremental cost isn't zero.
      - jrpelkonen 3y ago
        From the linked thread: > The most difficult issue to get right is cache invalidation. For sure, right up there with naming things and off-by-1s.
dmitrygr 3y ago
VDSO is designed for things that should be fast and are called often. There is absolutely no reason to call those functions often. The only time your PID would change from a previous value obtained from that very same function is in the child, after a call to fork(), which is itself so heavy, that it would dwarf your calls to getpid
- vlovich123 3y ago
  Is it a scarce resource? For what it’s worth when the caching was removed from glibc it caused a performance problem in libsystemd which had a tight loop to detect when a process was forked. So while this may be true in many cases, there’s clearly cases where it’s not and your answer doesn’t explain why getpid isn’t a vdso.
  - dmitrygr 3y ago
    Memory is always a scarce resource. However, a big you make the vdso, that amount of memory, multiplied by the number of processes is the amount wasted. In reality, it will be more, because of the required additional page tables to map it at an address range that is not commonly used. Also, what sort of raving lunatic had a busy loop checking the current process PID? Who allowed such a person access to a compiler? That seems like the bigger problem.
    - charcircuit 3y ago
      >multiplied by the number of processes Why aren't the pages shared like other dynamic libraries?
      - fweimer 3y ago
        If we put the PID into the vDSO, this data page can no longer be shared among different processes (at least not in the same container). We could use the rseq area for PID and TID.
      - dmitrygr 3y ago
the8472 3y ago
linux can set the uid per thread, afaik the vdso page is shared across threads.
vocram 3y ago
Because what getpid returns can change during the lifetime of a process, if it moves to a different PID namespace. I guess updating the vdso every time that happens is not worth the little gains.
- st_goliath 3y ago
  > ... can change during the lifetime of a process, ... Fun fact: this is already an issue for the vdso. gettimeofday(2) can use the CPU builtin cycle counters, but it needs information from the kernel to convert cycles to an actual timestamp (start and scale). This information too can change during the runtime. To not have userspace trampled over by the kernel, the vdso contains an open-coded spinlock that is used when accessing this information. I learnt about this while debugging a fun issue with a real-time co-kernel where the userspace thread occasionally ended up deadlocking inside gettimeofday and triggering the watchdog :-)
  - vacuity 3y ago
    Does avoiding userspace being trampled by the kernel mean avoiding a context switch? Does the kernel write to userspace-accessible memory that the spinlock guards? Unrelated, but what does "open-coded" mean? I never seem to find an obvious answer online.
    - aktau 3y ago
      > Unrelated, but what does "open-coded" mean? I never seem to find an obvious answer online. In my understanding, open-coded means something akin to "manually inlined". Or: written inline while an acceptable alternative exists as a function.

Anyone know why getpid/getuid still aren’t implemented as vdso?

tptacek 3y ago

When are you ever calling getuid in a tight loop?

bitcharmer 3y ago
GP's question is perfectly valid. It doesn't have to be called within a tight loop at all. It could be a latency sensitive routine for example. I can see at least a few real life applications where it would make sense to have the syscall vDSO'd.
- tptacek 3y ago
  What's one of them?
  - vlovich123 3y ago
    https://bugzilla.redhat.com/show_bug.cgi?id=1469670 https://bugzilla.redhat.com/show_bug.cgi?id=1469670 I would appreciate if someone explained why it’s not a vdso rather than just repeating it’s not necessary like that’s a sufficient explanation.
    - masklinn 3y ago
      It’s not a VDSO because it was never added as one. “Not a VDSO” is the default, a VDSO is additional complexity and maintenance so you need to justify its addition / existence, not its non-existence. Also given https://ipfs.io/ipfs/QmdA5WkDNALetBn4iFeSepHjdLGJdxPBwZyY47ir1bZGAK/comp/linux/getpid_caching.html https://ipfs.io/ipfs/QmdA5WkDNALetBn4iFeSepHjdLGJdxPBwZyY47i... while Linus may have changed tack in the decades since I would not expect much support from stating getpid is performance critical to you.
    - tptacek 3y ago
      I think we're just talking past each other. I'm asking why you'd want to vDSO getuid(), not getpid(). I can imagine cases where you'd repeatedly be calling getpid().
      - vlovich123 3y ago
        Eh. All of these things requiring a context switch seems alien to me. So it’s less of a use case and more “just make it fast” since the incremental cost should be 0?
        loeg 3y ago
        Well, the incremental cost isn't zero.
    - jrpelkonen 3y ago
      From the linked thread: > The most difficult issue to get right is cache invalidation. For sure, right up there with naming things and off-by-1s.

dmitrygr 3y ago

VDSO is designed for things that should be fast and are called often. There is absolutely no reason to call those functions often. The only time your PID would change from a previous value obtained from that very same function is in the child, after a call to fork(), which is itself so heavy, that it would dwarf your calls to getpid

vlovich123 3y ago
Is it a scarce resource? For what it’s worth when the caching was removed from glibc it caused a performance problem in libsystemd which had a tight loop to detect when a process was forked. So while this may be true in many cases, there’s clearly cases where it’s not and your answer doesn’t explain why getpid isn’t a vdso.
- dmitrygr 3y ago
  Memory is always a scarce resource. However, a big you make the vdso, that amount of memory, multiplied by the number of processes is the amount wasted. In reality, it will be more, because of the required additional page tables to map it at an address range that is not commonly used. Also, what sort of raving lunatic had a busy loop checking the current process PID? Who allowed such a person access to a compiler? That seems like the bigger problem.
  - charcircuit 3y ago
    >multiplied by the number of processes Why aren't the pages shared like other dynamic libraries?
    - fweimer 3y ago
      If we put the PID into the vDSO, this data page can no longer be shared among different processes (at least not in the same container). We could use the rseq area for PID and TID.
    - dmitrygr 3y ago

the8472 3y ago

linux can set the uid per thread, afaik the vdso page is shared across threads.

vocram 3y ago

Because what getpid returns can change during the lifetime of a process, if it moves to a different PID namespace. I guess updating the vdso every time that happens is not worth the little gains.

st_goliath 3y ago
> ... can change during the lifetime of a process, ... Fun fact: this is already an issue for the vdso. gettimeofday(2) can use the CPU builtin cycle counters, but it needs information from the kernel to convert cycles to an actual timestamp (start and scale). This information too can change during the runtime. To not have userspace trampled over by the kernel, the vdso contains an open-coded spinlock that is used when accessing this information. I learnt about this while debugging a fun issue with a real-time co-kernel where the userspace thread occasionally ended up deadlocking inside gettimeofday and triggering the watchdog :-)
- vacuity 3y ago
  Does avoiding userspace being trampled by the kernel mean avoiding a context switch? Does the kernel write to userspace-accessible memory that the spinlock guards? Unrelated, but what does "open-coded" mean? I never seem to find an obvious answer online.
  - aktau 3y ago
    > Unrelated, but what does "open-coded" mean? I never seem to find an obvious answer online. In my understanding, open-coded means something akin to "manually inlined". Or: written inline while an acceptable alternative exists as a function.