5 ms·

Some portable / embedded databases come to mind. Also "normal" databases doing replication initiation, and replication re-sync. And lastly backup, restore, tar,

Some portable / embedded databases come to mind. Also "normal" databases doing replication initiation, and replication re-sync. And lastly backup, restore, tar, etc with small files. For files under a handful of pages long mmap() isn't a big gain. Another syscall I think that might cause issues is gettimeofday(), that particular call has been optimised to the nth degree, and lots of user programs spam the crap out of it (mostly necessarily), especially networking and streaming programs. It would be interesting to see how much of an overhead percentagewise page table isolation will cost, and its effects on low end media devices, et al.

amluto 9y ago
vDSO-based timing is unaffected.
pm215 9y ago
Linux gettimeofday these days is implemented in the 'vdso', which is code provided by the kernel that runs solely in userspace. So it's not a syscall in the 'privilege level switch by executing insn that takes an exception' sense and shouldn't be affected by the syscall-entry/exit path becoming more expensive.
- tankenmate 9y ago
  Does this also apply to vsyscall's being emulated? Will this mean that older static binaries will no longer run? or just suffer a penalty as well?
  - wolf550e 9y ago
    Linux kernel has a compatibility guarantee to the user space visible API, so static binaries will continue to run. If the static binary is so old it does not know about vdso and uses regular syscall to query time, it will be slowed down.
  - tankenmate 9y ago
    This topic got me to look at the vDSO for my own machine so I wrote a short Perl program to dump your kernel's vDSO. https://pastebin.com/UnQX5U1f https://pastebin.com/UnQX5U1f
    - tankenmate 9y ago
      I added a quick repo to github if you want to clone or send pull requests for architectures apart from 64bit LE. https://github.com/mattkeenan/dump-vdso https://github.com/mattkeenan/dump-vdso
  - amluto 9y ago
    Emulated vsyscalls were already very slow and will be even slower on a patched kernel. They'll still work, though.

amluto 9y ago

vDSO-based timing is unaffected.

pm215 9y ago

Linux gettimeofday these days is implemented in the 'vdso', which is code provided by the kernel that runs solely in userspace. So it's not a syscall in the 'privilege level switch by executing insn that takes an exception' sense and shouldn't be affected by the syscall-entry/exit path becoming more expensive.

tankenmate 9y ago
Does this also apply to vsyscall's being emulated? Will this mean that older static binaries will no longer run? or just suffer a penalty as well?
- wolf550e 9y ago
  Linux kernel has a compatibility guarantee to the user space visible API, so static binaries will continue to run. If the static binary is so old it does not know about vdso and uses regular syscall to query time, it will be slowed down.
- tankenmate 9y ago
  This topic got me to look at the vDSO for my own machine so I wrote a short Perl program to dump your kernel's vDSO. https://pastebin.com/UnQX5U1f https://pastebin.com/UnQX5U1f
  - tankenmate 9y ago
    I added a quick repo to github if you want to clone or send pull requests for architectures apart from 64bit LE. https://github.com/mattkeenan/dump-vdso https://github.com/mattkeenan/dump-vdso
- amluto 9y ago
  Emulated vsyscalls were already very slow and will be even slower on a patched kernel. They'll still work, though.