Very well. The API Glauber (the author) describes has always been a good API for performance even with old HDDs and old CPUs.
In fact with very old CPUs the reduction in memory copies and system calls was more significant than it is now. The extra control over memory use with direct I/O is beneficial on some lower-end embedded systems too, e.g. video streaming from HDD on low memory systems.
It's just that before fast SSDs, there wasn't as much motivation to get the "best" I/O performance via complex APIs, because most of the time overhead was dominated by the HDD performance itself. (This was less true for big, fast RAIDs though.)
There was some benefit in a small amount of parallelism with HDDs, to improve block sorting, but that was usually best achieved with a few threads or processes, which is still a simple API to use, just read() and write() syscalls.
The only things really worth doing a complex API for before were O_DIRECT+AIO together, and even then they need a well-written, I/O-aware application to make them really worth using. In general, those applications have tended to be databases and VM hypervisors, but I've also seen it done for optimized file streaming to/from HDD on embedded systems. Though beneficial, the Linux AIO implementation had problems for a long time, even with O_DIRECT in some cases (such as filling holes in sparse files and extending files); so it was never reliably "true" async I/O. And there was no memory-buffer transfer and system call elision as there is with io_uring.
Now there is more motivation, so the API has been improved. O_DIRECT+AIO+io_uring is a better combination. The benefits are increasingly worth the effort for more kinds of applications due to the faster SSDs, and the SSDs' ability to handle large I/O request queues. But they would have been a good API combination for performance 20 years ago too.
Very well. The API Glauber (the author) describes has always been a good API for performance even with old HDDs and old CPUs.
In fact with very old CPUs the reduction in memory copies and system calls was more significant than it is now. The extra control over memory use with direct I/O is beneficial on some lower-end embedded systems too, e.g. video streaming from HDD on low memory systems.
It's just that before fast SSDs, there wasn't as much motivation to get the "best" I/O performance via complex APIs, because most of the time overhead was dominated by the HDD performance itself. (This was less true for big, fast RAIDs though.)
There was some benefit in a small amount of parallelism with HDDs, to improve block sorting, but that was usually best achieved with a few threads or processes, which is still a simple API to use, just read() and write() syscalls.
The only things really worth doing a complex API for before were O_DIRECT+AIO together, and even then they need a well-written, I/O-aware application to make them really worth using. In general, those applications have tended to be databases and VM hypervisors, but I've also seen it done for optimized file streaming to/from HDD on embedded systems. Though beneficial, the Linux AIO implementation had problems for a long time, even with O_DIRECT in some cases (such as filling holes in sparse files and extending files); so it was never reliably "true" async I/O. And there was no memory-buffer transfer and system call elision as there is with io_uring.
Now there is more motivation, so the API has been improved. O_DIRECT+AIO+io_uring is a better combination. The benefits are increasingly worth the effort for more kinds of applications due to the faster SSDs, and the SSDs' ability to handle large I/O request queues. But they would have been a good API combination for performance 20 years ago too.