Received: by 2002:a25:c205:0:0:0:0:0 with SMTP id s5csp984627ybf; Sat, 29 Feb 2020 21:40:49 -0800 (PST) X-Google-Smtp-Source: APXvYqzvuqsxoZ0tyWtlTYQtiayi0EfkYmd9eZwID6Cv1PIFHxYgike7znue8CiNdwpGQiml5LtT X-Received: by 2002:aca:ebcf:: with SMTP id j198mr6472502oih.115.1583041249578; Sat, 29 Feb 2020 21:40:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1583041249; cv=none; d=google.com; s=arc-20160816; b=qqGstmo1N6y/e7guQXuWN7cMPiBSUGeeggntdbfp36ws+EZLwizdvhWWH76/FLSi/X VuR4uTJnYpFyVvN+UHOUWOpEiv3F1XbG1RUqaxelguvkfrI1/l147od8wcJ7Iy5Q0q83 /RGpTBeD/BToYwE4PJOjo6CWjceAHLY03wNjYktIBTB8LXFMcRzFJZ6poHOAMSb8EytT G2cpQOEQVoRfnaqorKdhQ41vWkPHsKGsyl6zAglHOhRnX9Kct2tduZJt+mHRDQZmee8l pzbhtO+GESK26kfxlyUR9lPj98W7TCwka/o0lORu4qX0EUn/kzu71DAlDrKnpQO1EvRf rXEA== 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:dkim-signature; bh=3YIHlD0M+k+yxPJl/fAAm98gZtg1wXJwtbyuwCIFlGI=; b=lJ9b1B+ImD1y51HnTiGa3D32fuacEHGILcwST2Xn23anodIdlGKZmdM/tpPACpG7oI fDRorTxWmpewA7NFY7LaBQFC+ttIBfb2fYIN2DU1hNk9iV8BsCu/bEyRrJqK4Wt17b78 Jnz1O7CxlSabPbX0F8+RIW5RYdxU/y+YimnmbrVpH19GHAKTNzq+4snacB5BoZE/nr7t rC7oQg1YGP5lTh0NyLv0T58nb9RXy7vMm0A76rjSHfBwX3o5I0XaehkETCCEpfkEgO4a dpIKPfFl2DhU0gChajuy4gyEwYS1+kKku4KQqU1Kni0er+hdO4nQi/xWFLDNag3w7n9z tfrg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LXAqKmma; 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=pass (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 s82si4488916oih.240.2020.02.29.21.40.36; Sat, 29 Feb 2020 21:40:49 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=LXAqKmma; 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=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726816AbgCAFkB (ORCPT + 99 others); Sun, 1 Mar 2020 00:40:01 -0500 Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120]:46925 "EHLO us-smtp-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725821AbgCAFkB (ORCPT ); Sun, 1 Mar 2020 00:40:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583041200; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3YIHlD0M+k+yxPJl/fAAm98gZtg1wXJwtbyuwCIFlGI=; b=LXAqKmmabnWn/rHjPi9dKiV6bGPSUzNPn3IfeAy5s7YIidFuVzAhmKqz05QSH3YiUtUQlX oOW8e08dsJ/fe13cUiKbUYq5q8HwE230oReJsicZyV0heUJZqTr+IuTtYA+vTjvwpb3BPS xJdOOxW5j4vpN4mR01362dWX9UpHXnw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-154-f3ljMdhqNtu_2RzLzpQL9A-1; Sun, 01 Mar 2020 00:39:58 -0500 X-MC-Unique: f3ljMdhqNtu_2RzLzpQL9A-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 8F082800D4E; Sun, 1 Mar 2020 05:39:56 +0000 (UTC) Received: from localhost (ovpn-12-59.pek2.redhat.com [10.72.12.59]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C15605D9C9; Sun, 1 Mar 2020 05:39:53 +0000 (UTC) Date: Sun, 1 Mar 2020 13:39:50 +0800 From: Baoquan He To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Segher Boessenkool , Andrew Morton , Oscar Salvador , Michal Hocko , Dan Williams , Wei Yang Subject: Re: [PATCH v2 2/2] mm/memory_hotplug: cleanup __add_pages() Message-ID: <20200301053950.GO24216@MiWiFi-R3L-srv> References: <20200228095819.10750-1-david@redhat.com> <20200228095819.10750-3-david@redhat.com> <20200228103442.GL24216@MiWiFi-R3L-srv> <65186cee-358a-5c23-49e0-5507730941ad@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <65186cee-358a-5c23-49e0-5507730941ad@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/28/20 at 12:14pm, David Hildenbrand wrote: > On 28.02.20 11:34, Baoquan He wrote: > > On 02/28/20 at 10:58am, David Hildenbrand wrote: > >> Let's drop the basically unused section stuff and simplify. The logic > >> now matches the logic in __remove_pages(). > >> > >> Cc: Segher Boessenkool > >> Cc: Andrew Morton > >> Cc: Oscar Salvador > >> Cc: Michal Hocko > >> Cc: Baoquan He > >> Cc: Dan Williams > >> Cc: Wei Yang > >> Signed-off-by: David Hildenbrand > >> --- > >> mm/memory_hotplug.c | 18 +++++++----------- > >> 1 file changed, 7 insertions(+), 11 deletions(-) > >> > >> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c > >> index 8fe7e32dad48..1a00b5a37ef6 100644 > >> --- a/mm/memory_hotplug.c > >> +++ b/mm/memory_hotplug.c > >> @@ -307,8 +307,9 @@ static int check_hotplug_memory_addressable(unsigned long pfn, > >> int __ref __add_pages(int nid, unsigned long pfn, unsigned long nr_pages, > >> struct mhp_restrictions *restrictions) > >> { > >> + const unsigned long end_pfn = pfn + nr_pages; > >> + unsigned long cur_nr_pages; > >> int err; > >> - unsigned long nr, start_sec, end_sec; > >> struct vmem_altmap *altmap = restrictions->altmap; > >> > >> err = check_hotplug_memory_addressable(pfn, nr_pages); > >> @@ -331,18 +332,13 @@ int __ref __add_pages(int nid, unsigned long pfn, unsigned long nr_pages, > >> if (err) > >> return err; > >> > >> - start_sec = pfn_to_section_nr(pfn); > >> - end_sec = pfn_to_section_nr(pfn + nr_pages - 1); > >> - for (nr = start_sec; nr <= end_sec; nr++) { > >> - unsigned long pfns; > >> - > >> - pfns = min(nr_pages, PAGES_PER_SECTION > >> - - (pfn & ~PAGE_SECTION_MASK)); > >> - err = sparse_add_section(nid, pfn, pfns, altmap); > >> + for (; pfn < end_pfn; pfn += cur_nr_pages) { > >> + /* Select all remaining pages up to the next section boundary */ > >> + cur_nr_pages = min(end_pfn - pfn, > >> + SECTION_ALIGN_UP(pfn + 1) - pfn); > >> + err = sparse_add_section(nid, pfn, cur_nr_pages, altmap); > > > > Honestly, I am not a big fan of this kind of code refactoring. The old > > code may span seveal more lines or define several several more veriables, > > but logic is clear, and no visible defect. It's hard to say how much we > > I'm sorry, but iterating over variables and not using a single one in > the body is definitely not clean, at least IMHO. Leftover from Hmm, sometime we do use iterator to loop over only, it's just not so good. People usually have their own preferred coding style, and try to optimize to remove the itch in heart, totally understand. I have no strong objection to this, as long as it gets support from reviewers, it's not a bad thing. > sub-section hotadd support. > > > can benefit from this kind of code simplifying, and reviewing it will take > > people more time. While for the code style consistency with > > __remove_page(), I would like to see it's merged. My personal opinion. > > Thanks! > > > -- > Thanks, > > David / dhildenb