Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:46546 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726786AbeK2MeD (ORCPT ); Thu, 29 Nov 2018 07:34:03 -0500 Date: Thu, 29 Nov 2018 09:30:00 +0800 From: Ming Lei To: Jens Axboe , Mike Snitzer , "Ewan D. Milne" Cc: linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Theodore Ts'o , Omar Sandoval , Sagi Grimberg , Dave Chinner , Kent Overstreet , Mike Snitzer , dm-devel@redhat.com, Alexander Viro , linux-fsdevel@vger.kernel.org, Shaohua Li , linux-raid@vger.kernel.org, David Sterba , linux-btrfs@vger.kernel.org, "Darrick J . Wong" , linux-xfs@vger.kernel.org, Gao Xiang , Christoph Hellwig , linux-ext4@vger.kernel.org, Coly Li , linux-bcache@vger.kernel.org, Boaz Harrosh , Bob Peterson , cluster-devel@redhat.com Subject: Re: [PATCH V12 00/20] block: support multi-page bvec Message-ID: <20181129012959.GC23249@ming.t460p> References: <20181126021720.19471-1-ming.lei@redhat.com> <7096bc4e-0617-29d0-a90d-ae7caf09a16d@kernel.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7096bc4e-0617-29d0-a90d-ae7caf09a16d@kernel.dk> Sender: linux-ext4-owner@vger.kernel.org List-ID: On Wed, Nov 28, 2018 at 06:44:00AM -0700, Jens Axboe wrote: > On 11/25/18 7:17 PM, Ming Lei wrote: > > Hi, > > > > This patchset brings multi-page bvec into block layer: > > > > 1) what is multi-page bvec? > > > > Multipage bvecs means that one 'struct bio_bvec' can hold multiple pages > > which are physically contiguous instead of one single page used in linux > > kernel for long time. > > > > 2) why is multi-page bvec introduced? > > > > Kent proposed the idea[1] first. > > > > As system's RAM becomes much bigger than before, and huge page, transparent > > huge page and memory compaction are widely used, it is a bit easy now > > to see physically contiguous pages from fs in I/O. On the other hand, from > > block layer's view, it isn't necessary to store intermediate pages into bvec, > > and it is enough to just store the physicallly contiguous 'segment' in each > > io vector. > > > > Also huge pages are being brought to filesystem and swap [2][6], we can > > do IO on a hugepage each time[3], which requires that one bio can transfer > > at least one huge page one time. Turns out it isn't flexiable to change > > BIO_MAX_PAGES simply[3][5]. Multipage bvec can fit in this case very well. > > As we saw, if CONFIG_THP_SWAP is enabled, BIO_MAX_PAGES can be configured > > as much bigger, such as 512, which requires at least two 4K pages for holding > > the bvec table. > > I'm pretty happy with this patchset at this point, looks like it just > needs a respin to address the last comments. My only concern is whether I will address the last comment from Omar on patch of '[PATCH V12 01/20] btrfs: remove various bio_offset arguments', we may use the approach in V11 simply. > it's a good idea to target this for 4.21, or if we should wait until > 4.22. 4.21 has a fairly substantial amount of changes in terms of block > already, it's not the best timing for something of this magnitude too. Yeah, I understand. > > I'm going back and forth on those one a bit. Any concerns with > pushing this to 4.22? My only one concern is about the warning of "blk_cloned_rq_check_limits: over max segments limit" on dm multipath, and seems Ewan and Mike is waiting for this fix. thanks, Ming