[lkml]   [2001]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Kiobuf-io-devel] Re: 1st glance at kiobuf overhead in kernel aio vs pread vs user aio

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

 \ /
  Last update: 2005-03-22 13:28    [W:0.057 / U:17.460 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site