Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1835796imu; Fri, 23 Nov 2018 00:36:35 -0800 (PST) X-Google-Smtp-Source: AFSGD/WQqOJAQWwWPO5JeKUa+1Pgt57xQ8jpU2Iu7YIM4wnyabY5LTXiQKSjgXwyHaIh6O+++2Ai X-Received: by 2002:a63:a112:: with SMTP id b18mr13265567pgf.440.1542962195883; Fri, 23 Nov 2018 00:36:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542962195; cv=none; d=google.com; s=arc-20160816; b=TlfvojVY0zg3zssxhSkjP2gQSllUO4l5HiYEBQufIkjiQb//qX4ZACh1vOyaDN2osa 4aS+U6SjS169MtYdlKQMLA2l5B5UOPtpAT8+/RxZaHEKM4pNLKaDNCewDcYpCcOVCUwF bV1DQe79X1fksecbemHnJfBJSZfuU6OVJC5q9jTOylFYtyXtEzPiELJp4SDTrXfMCH41 df2x7cHv4vvCylSrPv8rfK5EqgD3NMOpFokGckw7olSTlB/wIhm7V5tWzMQx/7h+2eOI wVTLTjsPIs/+8nE1vkR5w9OMppA42Y0terldS+TGzL/L/5upPyBSQ01VDKUQxgCHgh7l AnJA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=IPW8BsVehRlscRwNqaraF5eDXND2PGoJIYOPBBISFnA=; b=EfeiSmNxB6PvNn7Or0eGFMzDROfGzixfXrm467at5TOOwEE+1bWIhNarNhaMA/eo+W tu0aVu/RrdATxUwqIO51FuVN4Iz2llf0WxwV9gAICl+vNKa+dWhAESgj1FYZdY/B5cA3 s+xFSHCr/AIw1HvPoUV3upfFrKlUKDR+usbZcKVArdG7bC2G33xmCP3Mvy5Se9LsHAS7 0SzHybcXwcXqneiUyyu5mNxqgWSNmTjXEqNT8/epkyQ38UahAzQs2TrpCRyPzu0A7SOx 8SdxVfx66QtDqDGpzs+F69dSxRdYzQy7zdX3xMVTiPk5Nwyrr8cVjBSVI1iktudSKxfM hIkA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u34si50000940pgk.24.2018.11.23.00.36.20; Fri, 23 Nov 2018 00:36:35 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2393702AbeKVUnQ (ORCPT + 99 others); Thu, 22 Nov 2018 15:43:16 -0500 Received: from verein.lst.de ([213.95.11.211]:57296 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731835AbeKVUnQ (ORCPT ); Thu, 22 Nov 2018 15:43:16 -0500 Received: by newverein.lst.de (Postfix, from userid 2407) id 1D1F968C22; Thu, 22 Nov 2018 11:04:28 +0100 (CET) Date: Thu, 22 Nov 2018 11:04:28 +0100 From: Christoph Hellwig To: Ming Lei Cc: Christoph Hellwig , Jens Axboe , 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 , linux-ext4@vger.kernel.org, Coly Li , linux-bcache@vger.kernel.org, Boaz Harrosh , Bob Peterson , cluster-devel@redhat.com Subject: Re: [PATCH V11 14/19] block: handle non-cluster bio out of blk_bio_segment_split Message-ID: <20181122100427.GA28871@lst.de> References: <20181121032327.8434-1-ming.lei@redhat.com> <20181121032327.8434-15-ming.lei@redhat.com> <20181121143355.GB2594@lst.de> <20181121153726.GC19111@ming.t460p> <20181121174621.GA6961@lst.de> <20181122093259.GA27007@ming.t460p> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181122093259.GA27007@ming.t460p> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 22, 2018 at 05:33:00PM +0800, Ming Lei wrote: > However, using virt boundary limit on non-cluster seems over-kill, > because the bio will be over-split(each small bvec may be split as one bio) > if it includes lots of small segment. The combination of the virt boundary of PAGE_SIZE - 1 and a max_segment_size of PAGE_SIZE will only split if the to me merged segment is in a different page than the previous one, which is exactly what we need here. Multiple small bvec inside the same page (e.g. 512 byte buffer_heads) will still be merged. > What we want to do is just to avoid to merge bvecs to segment, which > should have been done by NO_SG_MERGE simply. However, after multi-page > is enabled, two adjacent bvecs won't be merged any more, I just forget > to remove the bvec merge code in V11. > > So seems we can simply avoid to use virt boundary limit for non-cluster > after multipage bvec is enabled? No, we can't just remove it. As explained in the patch there is one very visible difference of setting the flag amd that is no segment will span a page boundary, and at least the iSCSI code seems to rely on that.