From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4EFA1C352A4 for ; Thu, 6 Feb 2020 23:44:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1E63A2464B for ; Thu, 6 Feb 2020 23:44:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1E63A2464B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AC3266B0003; Thu, 6 Feb 2020 18:44:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A73976B0006; Thu, 6 Feb 2020 18:44:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9892C6B0007; Thu, 6 Feb 2020 18:44:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0124.hostedemail.com [216.40.44.124]) by kanga.kvack.org (Postfix) with ESMTP id 80C0F6B0003 for ; Thu, 6 Feb 2020 18:44:28 -0500 (EST) Received: from smtpin25.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 44658441A for ; Thu, 6 Feb 2020 23:44:28 +0000 (UTC) X-FDA: 76461333816.25.bomb25_61259ad03de3e X-HE-Tag: bomb25_61259ad03de3e X-Filterd-Recvd-Size: 4438 Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Thu, 6 Feb 2020 23:44:27 +0000 (UTC) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2020 15:44:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,411,1574150400"; d="scan'208";a="225191059" Received: from richard.sh.intel.com (HELO localhost) ([10.239.159.54]) by orsmga008.jf.intel.com with ESMTP; 06 Feb 2020 15:44:23 -0800 Date: Fri, 7 Feb 2020 07:44:40 +0800 From: Wei Yang To: David Hildenbrand Cc: Baoquan He , linux-kernel@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, richardw.yang@linux.intel.com, mhocko@suse.com, osalvador@suse.de Subject: Re: [PATCH] mm/hotplug: Adjust shrink_zone_span() to keep the old logic Message-ID: <20200206234440.GA14560@richard> Reply-To: Wei Yang References: <20200206053912.1211-1-bhe@redhat.com> <7ecaf36f-9f70-05bd-05fc-6dec82b7d559@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7ecaf36f-9f70-05bd-05fc-6dec82b7d559@redhat.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Feb 06, 2020 at 09:50:07AM +0100, David Hildenbrand wrote: >On 06.02.20 06:39, Baoquan He wrote: >> In commit 950b68d9178b ("mm/memory_hotplug: don't check for "all holes" >> in shrink_zone_span()"), the zone->zone_start_pfn/->spanned_pages >> resetting is moved into the if()/else if() branches, if the zone becomes >> empty. However the 2nd resetting code block may cause misunderstanding. >> >> So take the resetting codes out of the conditional checking and handling >> branches just as the old code does, the find_smallest_section_pfn()and >> find_biggest_section_pfn() searching have done the the same thing as >> the old for loop did, the logic is kept the same as the old code. This >> can remove the possible confusion. >> >> Signed-off-by: Baoquan He >> --- >> mm/memory_hotplug.c | 14 ++++++-------- >> 1 file changed, 6 insertions(+), 8 deletions(-) >> >> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c >> index 089b6c826a9e..475d0d68a32c 100644 >> --- a/mm/memory_hotplug.c >> +++ b/mm/memory_hotplug.c >> @@ -398,7 +398,7 @@ static unsigned long find_biggest_section_pfn(int nid, struct zone *zone, >> static void shrink_zone_span(struct zone *zone, unsigned long start_pfn, >> unsigned long end_pfn) >> { >> - unsigned long pfn; >> + unsigned long pfn = zone->zone_start_pfn; >> int nid = zone_to_nid(zone); >> >> zone_span_writelock(zone); >> @@ -414,9 +414,6 @@ static void shrink_zone_span(struct zone *zone, unsigned long start_pfn, >> if (pfn) { >> zone->spanned_pages = zone_end_pfn(zone) - pfn; >> zone->zone_start_pfn = pfn; >> - } else { >> - zone->zone_start_pfn = 0; >> - zone->spanned_pages = 0; >> } >> } else if (zone_end_pfn(zone) == end_pfn) { >> /* >> @@ -429,10 +426,11 @@ static void shrink_zone_span(struct zone *zone, unsigned long start_pfn, >> start_pfn); >> if (pfn) >> zone->spanned_pages = pfn - zone->zone_start_pfn + 1; >> - else { >> - zone->zone_start_pfn = 0; >> - zone->spanned_pages = 0; >> - } >> + } >> + >> + if (!pfn) { >> + zone->zone_start_pfn = 0; >> + zone->spanned_pages = 0; >> } >> zone_span_writeunlock(zone); >> } >> > >So, what if your zone starts at pfn 0? Unlikely that we can actually >offline that, but still it is more confusing than the old code IMHO. >Then I prefer to drop the second else case as discussed instead. > Sorry, I just catch up with this thread. If zone starts at 0, find_smallest_section_pfn() will be called only when we want to remove the first section [0, secion_size]. Then find_smallest_section_pfn() return value has two possibilities: * a non-0 section pfn if it still has * 0 if the zone is empty This looks good to me. Or I may misunderstand your point, would you mind sharing more light on your finding? Thanks :-) >-- >Thanks, > >David / dhildenb -- Wei Yang Help you, Help me