Re: 2.6.13-mm1

[Benjamin LaHaise <bcrl@linux.intel.com>]

On Fri, Sep 02, 2005 at 01:57:35PM -0700, Andrew Morton wrote:
> Cons:
> 
> - Additional arguments to various fastpath functions

One possibility is to split the async and sync versions by way of inline 
functions.  That will result in more icache pressure, though, which makes 
it a questionable optimization.

> - Additional code size
> 
> - Additional code complexity

These are general concerns of all new features.  It is possible to split 
the code out into separate codepaths (the 2.4 async read/write paths were 
completely new), but that cuts down on code sharing between the traditional 
sync read/writes and async code.  If that is a requirement for merging, 
then they certainly could be split out and grown in a separate aio module, 
but that leads to other maintenence headches.

The flip side of this question is that we already have O_DIRECT and all of 
its associated overhead, yet the vast majority of systems don't use it in 
the course of day to day operation.  Maybe we should have config options 
for these things, but where does the line get drawn?

> - Significantly degrades collective understanding of how the VFS works.

That can be improved through the use of debugging options to teach people 
that aio_* functions should not block, which is the only real difference 
between async and non-async functions -- if you'd block, return -EIOCBRETRY 
instead.

> Pros:
> 
> - Unclear.

We already have a number of users demanding buffered filesystem aio -- the 
UML patches to use aio just went in.  Samba is able to make use of aio.  
There are lots of high performance server applications which require aio 
and filesystem caching (think iSCSI servers, web servers/caches).  Right 
now the only way to do that is via threads, which brings into play a lot 
of other overhead.  AIO is one of the last areas in which we don't provide 
a suitable implementation for use in normal applications, only highly 
specialised database users.

		-ben