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@xxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
