Messages in this thread |  | | Date | Sat, 3 Feb 2001 00:14:36 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: [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.
Ingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |