On 09/20/2017 05:49 PM, Christoph Hellwig wrote:
On Wed, Sep 20, 2017 at 02:11:49PM +0300, Avi Kivity wrote:
I think it's still preferable to avoid a workqueue and its non-deterministic
latencies and context switches if we can prove that a particular iocb will
not require a synchronous operation. If that can be done then 4.13 nowait
aio also works - the user provides the workqueue equivalent. The only
problem is if we can't prove in advance that an iocb will require blocking.
The code is generally pessimistic and bails out rather too often.
The only issue not solved is memory allocation, at the moment we could
still block on them so this will need some more work. For XFS direct
I/O the only memory allocations in that path should be the bios.
I think we can ignore blocking on memory allocation. It affects all
system calls and even just regular user memory access - if you're
starved for memory you're likely to have text and data pages swapped
out. An application that wants aio should be prepared to avoid starving
the kernel for memory.
1. Short writes - just ignore the tail of a too-large iovec. May cause
buggy applications to fail, so probably not a good idea.
We could still do it the same way we did RWF_NOWAIT - require an
explicit opt-in for what should be the defalt behavior because we
change the historic behavior.
Yes.
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
