Toward non-blocking asynchronous I/O

Toward non-blocking asynchronous I/O

Posted Jun 1, 2017 16:22 UTC (Thu) by oever (guest, #987)
Parent article: Toward non-blocking asynchronous I/O

I appreciate the work on asynchronous I/O very much. There is a lot of potential to improve software with AIO. A good example I came across recently is the venerable find.

find is a single-threaded application that uses blocking IO. For each directory that it reads it does one or more getdents calls. These calls are done sequentially. find could be sped up by doing many calls at the same time.

Consider the extreme case where each subsequent directory is on the opposite site of the disk. The disk head would travel to the other side of the disk for each directory. The kernel IO scheduler cannot help because it only knows about the next location.

If 100 parallel requests were done instead of one, the IO scheduler would handle them in an efficient and quick manner: it would read the nearest entries first. It is possible to send parallel getdents requests with threads. This requires one thread per parallel request: quite an overhead. libuv does this with a thread pool. This approach can roughly double the speed of find for a cold cache.

If this would be implemented with libaio, the thread overhead could be eliminated.

---

to post comments