top | item 22509432

(no title)

nominatronic | 6 years ago

This is basically the idea of io_uring [0], although that mechanism is specific to certain I/O operations rather than being a generic queuing system for syscalls.

[0] https://lwn.net/Articles/776703/

discuss

order

wahern|6 years ago

Before io_uring there were many failed proposals for a general purpose, asynchronous interface to wrap blocking syscalls. One of these, "syslets", was literally a mechanism for batching arbitrary syscalls: https://lwn.net/Articles/221887/

> Syslets are small, simple, lightweight programs (consisting of system-calls, 'atoms') that the kernel can execute autonomously (and, not the least, asynchronously), without having to exit back into user-space. ....

> Syslets consist of 'syslet atoms', where each atom represents a single system-call. These atoms can be chained to each other: serially, in branches or in loops.

correct_horse|6 years ago

Thanks for sharing. It's encouraging that something at least resembling what I came up with was considered.

anonymousDan|6 years ago

Any thoughts on why they failed?

JoshTriplett|6 years ago

Long-term, io_uring will almost certainly going to provide more operations than just I/O.

the8472|6 years ago

Batched virtual memory updates (mmap/munmap/madvise) could be a boon for allocators and garbage collectors since the cost of TLB shootdowns could be amortized.

Similarly if all the syscalls done between fork and exec could be squeezed into a single uring chain without any intervening userspace code then the kernel could skip some costly virtual memory operations, bringing us closer to posix_spawn behavior.