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

[Benjamin LaHaise]

Hey Ingo,

On Fri, 2 Feb 2001, Ingo Molnar wrote:

> - 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?

Thanks!  Right now the code does the page cache lookup allocations and
lookups in the caller's thread, the write path then attempts to lock all
pages sequentially during io using the async page locking function
wtd_lock_page.  I've tried to get this close to some of the ideas proposed
by Jeff Merkey, and have implemented async page and buffer locking
mechanisms so far.  The down in the write path is still synchronous,
mostly because I want some feedback before going much further down this
path.  The read path verifies the up2date state of individual pages, and
if it encounters one which is not, then it queues the request for the
worker thread which calls readpage on all the pages that need updating.

> - 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?

I hadn't thought of that, but I don't think it would be too hard to
implement.  We need to decide the degree to which state machine based code
should be used within the kernel.  For many things it can potentially have
a lower overhead than existing kernel code simply because the stack usage
is much flatter.

> 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.]

;-)  I still want to get the network glue done to merge with the zerocopy
patches as buffer management for things like large LDAP servers isn't
going to work that well with the close-to-posix aio_read.  Of course, this
depends on the aio sendfile code that's coming...

		-ben