Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp1888389imm; Sun, 27 May 2018 19:31:30 -0700 (PDT) X-Google-Smtp-Source: AB8JxZrxIxvk/GIxRk5rc5YnnluJNndxvTwbfYo8e5ne4V7ydL7vgcFJJ+VstVXiHy+bmdcZPare X-Received: by 2002:a17:902:2bc5:: with SMTP id l63-v6mr11513382plb.299.1527474690308; Sun, 27 May 2018 19:31:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527474690; cv=none; d=google.com; s=arc-20160816; b=Cma7Ewr2FTb4+gyLsTxK6RgzPjqXIlU0z5INJ91dr97WiNYtwy5vNJo7PGB5RAyXaA Sp5YU+7mxQEN1zXvh1bm8fTS4D+HQhupQR7Ix70hANzboaTxB0VROhDNicyUzRC0Iavw WXM1cWkXT5QF7Kh81SBH5Z2lSii6SR+jAPTvJR9MhlxVhBNmDH/5fvKiIQbeuE4Km5Ae DKMI0zqUw4nYX+Vvvar7W1sQfbN1w0ncQ+MnB+YKX8w/iHL5eFpp5m/AtgY67kqAxKkW siHY+dqZpJs1JTTjSurGEqhmn/yL1b8KC06xokIH3vdgWSbfBdIrlrwI0GLOht3XwZ2X Actg== 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:arc-authentication-results; bh=tqSxPX2jA4RlCWSUxTNhinP2G4zTq58qOMnqsDfsHrs=; b=fMpKtoK45jfTdaSdV0E733jUGZj3v5xcyGt+bGG0HQULYLYpOVjLRwSlSslM4FASFI CK0UVHfdM6qMFeO1SaGMrmlusA18sUm4eQrFIlH3mqF6LzQmv9WKA+eyvHxBMyB5DEkh +r4K6034LRbXwGtASzGsjtdX71v6nr+fVjz/n6aqzrKymF2Jqz5Du/1AgZSgpaqGu36M VL/XcN96oZBwkK5DTQkIQQUqmsnv/JmwjEPk1L0EzMqeWIp7TZnKk9KqIJxgY4kt+uQX KxqkzhTReig6hSSlYcatyTOHIx5F5x/BcG6f86AIgsdhiWEtHZUG+lOzZi/w5dY6SuOv 6Pew== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r17-v6si9291407pls.597.2018.05.27.19.31.15; Sun, 27 May 2018 19:31:30 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753017AbeE1CbF (ORCPT + 99 others); Sun, 27 May 2018 22:31:05 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:38878 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752952AbeE1CbE (ORCPT ); Sun, 27 May 2018 22:31:04 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 71D4D400E9BA; Mon, 28 May 2018 02:31:03 +0000 (UTC) Received: from ming.t460p (ovpn-12-91.pek2.redhat.com [10.72.12.91]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E0C83111DD01; Mon, 28 May 2018 02:30:47 +0000 (UTC) Date: Mon, 28 May 2018 10:30:43 +0800 From: Ming Lei To: Jens Axboe Cc: Kent Overstreet , Christoph Hellwig , Alexander Viro , David Sterba , Huang Ying , linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Theodore Ts'o , "Darrick J . Wong" , Coly Li , Filipe Manana Subject: Re: [RESEND PATCH V5 00/33] block: support multipage bvec Message-ID: <20180528023042.GC26790@ming.t460p> References: <20180525034621.31147-1-ming.lei@redhat.com> <20180525045306.GB8740@kmo-pixel> <8aa4276d-c0bc-3266-aa53-bf08a2e5ab5c@kernel.dk> <20180527072332.GA18240@ming.t460p> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Mon, 28 May 2018 02:31:03 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Mon, 28 May 2018 02:31:03 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'ming.lei@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, May 27, 2018 at 07:44:52PM -0600, Jens Axboe wrote: > On 5/27/18 1:23 AM, Ming Lei wrote: > > On Fri, May 25, 2018 at 10:30:46AM -0600, Jens Axboe wrote: > >> On 5/24/18 10:53 PM, Kent Overstreet wrote: > >>> On Fri, May 25, 2018 at 11:45:48AM +0800, Ming Lei wrote: > >>>> Hi, > >>>> > >>>> This patchset brings multipage bvec into block layer: > >>> > >>> patch series looks sane to me. goddamn that's a lot of renaming. > >> > >> Indeed... I actually objected to some of the segment -> page > >> renaming, but it's still in there. The foo2() temporary functions > >> also concern me, we all know there's nothing more permanent than a > >> temporary fixup. > > > > Jens, I remember I explained the renaming story to you in lsfmm a bit: > > > > 1) the current naming of segment is actually wrong, since every segment > > only stores one single-page vector > > > > 2) the most important part is that once multipage bvec is introduced, > > if the old _segment naming is still kept, it can be very confusing, > > especially no good name is left for the helpers of dealing with real > > segment. > > Yes, we discussed exactly this, which is why I'm surprised you went > ahead with the same approach. I told you I don't like tree wide renames, Maybe I misunderstood your point, that isn't strange given my poor english, :-) > if they can be avoided. I'd rather suffer some pain wrt page vs segments > naming, and then later do a rename (if it bothers us) once the dust has > settled on the interesting part of the changes. > > I'm very well away of our current naming and what it signifies. With > #1, you are really splitting hairs, imho. Find a decent name for > multiple segment. Chunk? OK, will try _chunk in next post. > > > For the foo2() temporary change, that is only for avoiding tree-wide > > change in one single tree, with this way, we can change sub-system one > > by one, but if you think it is good to do tree-wide conversion in one > > patch, I am fine to do it in next version. > > It's still a painful middle step. I hate the conversion too, but looks it can't be avoided since bio_for_each_segment_all() has to be changed. Could you share us what your favorite approach is for this conversion? Thanks, Ming