Hi M, > > > > What you missed is that the native aio system calls require O_DIRECT. > > > > > > > > > > Thanks, that made it work. It seems without O_DIRECT it's just like > > > aio_* but without the separate thread. But I now get the "benefits" of > > > O_DIRECT for free... > > > > That is awesome news; I was worried. I saw that about O_DIRECT in the > > doc but assumed you were doing it. > > > > > Where did you see that? I reverted to the kernel source where indeed I > saw __generic_file_aio_read() in mm/filemap.c check for O_DIRECT. > > io_submit(3), io_setup(3) etc don't mention O_DIRECT. Even the example > in io(3) doesn't do O_DIRECT, so it must be broken. The example has no > means to see if it is in fact a non blocking system call. But io(3) > states "The libaio library defines a new set of I/O operations which > can significantly reduce the time an application spends waiting at I/O. > The new functions allow a program to initiate one or more I/O operations > and then immediately resume normal work while the I/O operations are > executed in parallel." Not in the linux man pages, but a few folks around have web pages I was able to google about actual behavior: http://lse.sourceforge.net/io/aio.html Like you, I trusted that the man pages actually described the behavior in my software design until the "nonblocking" read and writev calls choked off the nonblocking sockets :-) Now I am writing extra test code for all system calls I consider using; not sure if there is actual public test code or not. You are absolutely right, the blocking behavior of libaio without specifying O_DIRECT should also definitely be in the man pages. Why isn't it an error to not specify O_DIRECT when that's the only way libaio to block devs is actual async io? It seems a bit odd to go to the trouble to use libaio if synchronous behavior is expected?! You might want to wait and see if my man patch even gets applied before going to the trouble to make another one. Alan Cox suggested I post a patch to spell out the actual behavior of the blocking "O_NONBLOCK" read and write class of calls. I did that and a number of us vetted the patch before I posted it to linux-man like a week ago, but no feedback there from Michael Kerrisk or anyone else yet. Maybe he's on holiday, or maybe someone else can also carry the man page pumpkin, I don't know... Either way I imagine lkml sees this over and over again and fixing the man pages would go a long way toward cutting down on confusion. - Mike -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
