On Jan 20, 2016 1:46 PM, "Dave Chinner" [off-list ref] wrote:

quoted

quoted

That said, I also agree that it would be interesting to hear what the
performance impact is for existing performance-sensitive users. Could
we make that "aio_may_use_threads()" case be unconditional, making
things simpler?

Making it unconditional is a goal, but some work is required before that
can be the case.  The O_DIRECT issue is one such matter -- it requires

some

quoted

changes to the filesystems to ensure that they adhere to the

non-blocking

quoted

nature of the new interface (ie taking i_mutex is a Bad Thing that users
really do not want to be exposed to; if taking it blocks, the code

should

quoted

punt to a helper thread).

Filesystems *must take locks* in the IO path.

I agree.

I also would prefer to make the aio code have as little interaction and
magic flags with the filesystem code as humanly possible.

I wonder if we could make the rough rule be that the only synchronous case
the aio code ever has is more or less entirely in the generic vfs caches?
IOW, could we possibly aim to make the rule be that if we call down to the
filesystem layer, we do that within a thread?

We could do things like that for the name loopkup for openat() too, where
we could handle the successful RCU loopkup synchronously, but then if we
fall out of RCU mode we'd do the thread.

    Linus