Re: [Kiobuf-io-devel] Re: 1st glance at kiobuf overhead in kernel aio vs pread vs user aio

From: Ingo Molnar (
Date: Fri Feb 02 2001 - 18:14:36 EST

On Fri, 2 Feb 2001, Benjamin LaHaise wrote:

> Thanks! Right now the code does the page cache lookup allocations and
> lookups in the caller's thread, [...]

(the killer is not the memory allocation(s), if there is enough RAM then
we can get a free page without having to block.)

The real problem is the implicit ->bmap() in readpage(). IMO this is the
tough part in AIO. There can be zillions of sub-IOs generated during
filesystem ->bmap(). Doing the data reads asynchronously is just about 30%
of the work, and as long as there is even a *single* inode-related
blocking point in the synchronous async IO path, the whole scheme remains
useless for practical applications. It does not matter that 90% of the IO
is asynchronous - if we are blocking on the remaining 10% then the whole
operation degrades to synchronous!

To make this work correctly, lowlevel filesystem code must be modified in
nontrivial ways. If this is easy then please give me a quick description
of how this is going to be done.

Plus there is the issue of not blocking in __wait_request() either.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

This archive was generated by hypermail 2b29 : Wed Feb 07 2001 - 21:00:16 EST