From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH 3/3] target: use vfs_bvec_read/write Date: Mon, 26 Jan 2015 17:59:12 +0100 Message-ID: <20150126165912.GA13669@lst.de> References: <1421593624-4462-1-git-send-email-hch@lst.de> <1421593624-4462-4-git-send-email-hch@lst.de> <20150125134304.GA21974@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , Al Viro , Jens Axboe , Nicholas Bellinger , Linux FS Devel , target-devel@vger.kernel.org To: Ming Lei Return-path: Content-Disposition: inline In-Reply-To: Sender: target-devel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mon, Jan 26, 2015 at 10:02:30AM +0800, Ming Lei wrote: > >> Sorry, I have one question: I understand one bvec should only cover > >> one page, but > >> one sg may cover lots of pages, so could ITER_BVEC handle that correctly? > > > > Each scatterlist entry only contains a single page, which is returned > > I mean scatterlist does not guarantee that, and one sg entry often > contains lots of pages, which DMA/bus address is continuous. But we still get away with using page_address(), so from the VM point of view that matters here it's the same as a single high order page. > > by sg_page(sg). The existing code already relies on it because it > > kmaps that page. > > If the existing target code path can guarantee that one sg entry > only contains one page, it should be better to use bio_vec explicitly > instead of scatterlist. While it allocates a single page per SGL entry (see target_alloc_sgl), it uses the scatterlist to allow drivers to dma map it for hardware access, so a scatterlist seems useful here.