4 ms·
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 lea
by 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 agoWhat's one of them?
- vlovich123 3y agohttps://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 agoIt’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 agoI 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 agoEh. 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 agoWell, the incremental cost isn't zero.
- jrpelkonen 3y agoFrom 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.