Re: [PATCH 4/5] iomap: implement direct I/O

2016-11-04 Thread Jens Axboe
On Fri, Nov 04 2016, Christoph Hellwig wrote: > This adds a full fledget direct I/O implementation using the iomap > interface. Full fledged in this case means all features are supported: > AIO, vectored I/O, any iov_iter type including kernel pointers, bvecs > and pipes, support for hole filling

[PATCH 5/5] xfs: use iomap_dio_rw

2016-11-04 Thread Christoph Hellwig
Straight switch over to using iomap for direct I/O - we already have the non-COW dio path in write_begin for DAX and files with extent size hints, so nothing to add there. The COW path is ported over from the old get_blocks version and a bit of a mess, but I have some work in progress to make it

[PATCH 4/5] iomap: implement direct I/O

2016-11-04 Thread Christoph Hellwig
This adds a full fledget direct I/O implementation using the iomap interface. Full fledged in this case means all features are supported: AIO, vectored I/O, any iov_iter type including kernel pointers, bvecs and pipes, support for hole filling and async apending writes. It does not mean

an iomap-based direct I/O implementation V2

2016-11-04 Thread Christoph Hellwig
Hi all, this series adds a new direct I/O implementation based on the iomap interface, and switches XFS to use it. The first two patches are a resend of my earlier series to remove the XFS iolock. They are needed for the lockdep assert in the new iomap code. The rest implements a new

[PATCH 3/5] fs: make sb_init_dio_done_wq available outside of direct-io.c

2016-11-04 Thread Christoph Hellwig
We want to use the per-sb completion workqueue from the new iomap direct I/O code. Signed-off-by: Christoph Hellwig --- fs/direct-io.c | 2 +- fs/internal.h | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/direct-io.c b/fs/direct-io.c index

Re: [PATCH 3/5] block: move poll code to blk-mq

2016-11-04 Thread Jens Axboe
On 11/04/2016 08:44 AM, Christoph Hellwig wrote: On Thu, Nov 03, 2016 at 01:45:05PM -0600, Jens Axboe wrote: The poll code is blk-mq specific, let's move it to blk-mq.c. This is a prep patch for improving the polling code. Signed-off-by: Jens Axboe Reviewed-by: Christoph Hellwig

Re: [PATCH V2 2/2] blk-mq: immediately dispatch big size request

2016-11-04 Thread Jens Axboe
On 11/04/2016 08:46 AM, Christoph Hellwig wrote: On Thu, Nov 03, 2016 at 10:00:58PM -0600, Jens Axboe wrote: I've applied 1-2 for 4.10, but we probably should look into unifying those parts of sq and mq in general. For instance, it doesn't seem to make a lot of sense why we'd depth limit sq and

Re: [PATCH V2 2/2] blk-mq: immediately dispatch big size request

2016-11-04 Thread Christoph Hellwig
On Thu, Nov 03, 2016 at 10:00:58PM -0600, Jens Axboe wrote: > I've applied 1-2 for 4.10, but we probably should look into unifying > those parts of sq and mq in general. For instance, it doesn't seem to > make a lot of sense why we'd depth limit sq and not mq. I've spent some time looking the the

Re: [PATCH 3/5] block: move poll code to blk-mq

2016-11-04 Thread Christoph Hellwig
On Thu, Nov 03, 2016 at 01:45:05PM -0600, Jens Axboe wrote: > The poll code is blk-mq specific, let's move it to blk-mq.c. This > is a prep patch for improving the polling code. > > Signed-off-by: Jens Axboe > Reviewed-by: Christoph Hellwig So I gave my ok earlier,