Re: switch loop and target to use ITER_BVEC iov_iter

[Christoph Hellwig <hch@lst.de>]

On Thu, Jan 22, 2015 at 12:11:18PM +0800, Ming Lei wrote:
> On Sun, Jan 18, 2015 at 11:07 PM, Christoph Hellwig <hch@lst.de> wrote:
> > This series adds two new helpers to easily read from and write to bio_bvecs,
> > and switches the loop driver and target file backend to use it.
> >
> > Using bio_vecs directly avoids the need to kmap individual elements in
> > the callers, which is epecially important in the target driver, and also
> > gets rid of the horrible splice code abuse hack in the loop driver.
> 
> IMO, from driver or kernel view, submit()/complete() model
> is very very common, and is more efficient because unnecessary
> context switch and process' creation can be avoided when concurrent
> read/write is needed for sake of performance, so I think kernel
> aio based API is better. My test result about kernel aio based loop
> shows CPU can be saved much with kernel AIO in [2].
> 
> Currently the kernel AIO based approach for loop(v2 patches, [1] [2])
> only handles direct I/O with ITER_BVEC, but it is quite easy to
> cover non-direct I/O by BVEC with supporting current submission.
> 
> For encrypt_type loop, it may be covered by kernel aio interface too.
> 
> I will try to cover the above two loop cases by kernel based AIO in
> v3, then the current ->write() and splice code may be removed once
> it is done.

We'll still need to support the buffered I/O case.  Some people may
rely on it for their workload performance, and other cases like
a filesystem with a small sector size ontop of a loop device on a
filesystem or device with a larger sector size won't even work at all
using direct I/O.

So we'll need something like my series to get started, and if aio
proves to win over usin a kernel direct I/O read/write (which I suspect it
will, but we'll need numbers) we can use aio for the direct I/O code
path.