LWN: Comments on "Toward non-blocking asynchronous I/O"

Toward non-blocking asynchronous I/O

oever — Fri, 02 Jun 2017 12:53:24 +0000

Alas, this plan cannot be executed while there is no LIO_GETDENTS in aiocb.

Toward non-blocking asynchronous I/O

peter-b — Fri, 02 Jun 2017 07:06:51 +0000

I think the problem is that older kernels ignore those bits entirely, rather than forcing them to be zeroed. So there's no reliable way to find out whether the flag's having any effect.

Toward non-blocking asynchronous I/O

ssmith32 — Fri, 02 Jun 2017 06:19:47 +0000

I'm assuming older kernels throw an error if they check the new flag, and it's set? Otherwise I can't understand why that matters...

Toward non-blocking asynchronous I/O

oever — Thu, 01 Jun 2017 16:22:06 +0000

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.

Would still be beneficial to have async fsync even with O_DIRECT

sitsofe — Wed, 31 May 2017 20:20:25 +0000

O_DIRECT implies that the I/O won't be left rolling around in the OS' cache but says nothing about whether it is still in the disk device's non-volatile cache. You could send all I/Os down with O_SYNC too but speeds will plummet. Thus it's still desirable to be able to send down an fsync (and it would have been preferable if submitting it didn't have to block)...

Toward non-blocking asynchronous I/O

ringerc — Wed, 31 May 2017 06:07:58 +0000

Last time I checked it seemed like we couldn't even trust the AIO layer to provide a reliable fsync() for buffered AIO, so it seems like it's pretty useless for anything except O_DIRECT.