From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ming Lei Subject: Re: switch loop and target to use ITER_BVEC iov_iter Date: Thu, 22 Jan 2015 12:11:18 +0800 Message-ID: References: <1421593624-4462-1-git-send-email-hch@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Cc: Al Viro , Jens Axboe , Nicholas Bellinger , Linux FS Devel , target-devel@vger.kernel.org To: Christoph Hellwig Return-path: Received: from youngberry.canonical.com ([91.189.89.112]:59810 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750935AbbAVELV (ORCPT ); Wed, 21 Jan 2015 23:11:21 -0500 In-Reply-To: <1421593624-4462-1-git-send-email-hch@lst.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Sun, Jan 18, 2015 at 11:07 PM, Christoph Hellwig 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. [1] http://marc.info/?l=linux-kernel&m=142116394225654&w=2 [2] http://marc.info/?l=linux-kernel&m=142116397525668&w=2 Thanks, Ming Lei