3 ms·
> Can an OS be rearchitected in ways that would mitigate the performance loss? The performance loss comes from extra overhead on syscalls, so it could be sides
by jsheard 9y ago
> Can an OS be rearchitected in ways that would mitigate the performance loss?
The performance loss comes from extra overhead on syscalls, so it could be sidestepped by allowing programs to do more work per syscall.
At its simplest that could mean adding more syscalls that perform the same operation over an arbitrarily long list of inputs (like linux's sendmmsg) but I would like to see kernels take inspiration from modern graphics APIs that allow arbitrarily long lists of arbitrary operations to be batched and executed with a single syscall. GPUs had this stuff figured out years ago.
- sanxiyn 9y agoNote that Red Hat patented batching syscalls... https://www.google.com/patents/US9038075 https://www.google.com/patents/US9038075
- bch 9y ago1) this is exciting, if not also brilliant 2) SQL transactions as prior art? If they’re successful w their patent, I sure hope there’s a way for BSDs to try it on.
- pkaye 9y agoRedHat has a patent promise that they will not enforce their patents against any free software that make use of their patents. https://www.redhat.com/en/about/patent-promise https://www.redhat.com/en/about/patent-promise
- rphlx 9y agoI agree with your basic point - a generic syscall batching mechanism would be a good thing - but it's worth noting that GPU workloads are usually much better suited for ginormous "fire and forget" command/command+data sequences. syscalls tend to be more interactive/round-trip-dependent, where syscall N+1 is at least partially determined by a userspace process doing something fairly complicated with the result of syscall N. This is a natural enemy of massive batching.