Re: 1st glance at kiobuf overhead in kernel aio vs pread vs user

[Ingo Molnar]

Ben,

- first of all, great patch! I've got a conceptual question: exactly how
does the AIO code prevent filesystem-related scheduling in the issuing
process' context? I'd like to use (and test) your AIO code for TUX, but i
do not see where it's guaranteed that the process that does the aio does
not block - from the patch this is not yet clear to me. (Right now TUX
uses separate 'async IO' kernel threads to avoid this problem.) Or if it's
not yet possible, what are the plans to handle this?

- another conceptual question. async IO doesnt have much use if many files
are used and open() is synchronous. (which it is right now) Thus for TUX
i've added ATOMICLOOKUP to the VFS - and 'missed' (ie. not yet
dentry-cached) VFS lookups are passed to the async IO threads as well. Do
you have any plans to add file-open() as an integral part of the async IO
framework as well?

once these issues are solved (or are they already?), i'd love to drop the
ad-hoc kernel-thread based async IO implementation of TUX and 'use the
real thing'. (which will also probably perform better) [Btw., context
switches are not that much of an issue in kernel-space, due to lazy TLB
switching. So basically in kernel-space the async IO threads are barely
more than a function call.]

	Ingo