3 ms·
The nout about aio in glibc documentation says the following: "The current Linux POSIX AIO implementation is provided in user space by glibc. This has a numbe
by zvrba 11y ago
The nout about aio in glibc documentation says the following:
"The current Linux POSIX AIO implementation is provided in user space by glibc. This has a number of limitations, most notably that maintaining multiple threads to perform I/O operations is expensive and scales poorly."
Why does it scale poorly? It shouldn't given a decent thread-pool implementation and lock-free queueing.
- mtanski 11y agoIt scales poorly because the underlying queue is not lock-free. It was designed in a much simpler time or slower drives (spinning disks). Even if you make it lock-free you still end up paying the communication cost (in/notification). Any time you move data to a different thread that's going to introduce latency (which matters on modern fast drives). Most of these thread pool implementations also suffer head of line blocking... eg. small and fast (page cache) requests get stuck behind long and slow requests. I know because, I've been fighting this stuff for all of my career. I've recently (in the last two years) tried to push upstream to Linux an a non-blocking page cache read. Thus you have a short circuit case for skipping the queue. In my tests it made samba file sharing ~ 23% faster. https://lwn.net/Articles/612483/ https://lwn.net/Articles/612483/ https://lwn.net/Articles/636967/ https://lwn.net/Articles/636967/ https://lwn.net/Articles/670231/ https://lwn.net/Articles/670231/ The preadv2 patches stalled... but Christoph revived them and now they are in the kernel. So what's need now is RWF_NONBLOCK.