Re: 2.6.13-mm1

Benjamin LaHaise
2005-09-06T15:27:55Z

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