Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp2088773ybv; Thu, 6 Feb 2020 15:45:49 -0800 (PST) X-Google-Smtp-Source: APXvYqwXsg49D1iZfV0JaVt6n6o/SywX7LJdu1vxoCrEv3HvbBg97+o3qys0uyDK8mvwBWEuwMWb X-Received: by 2002:a9d:23b5:: with SMTP id t50mr510510otb.122.1581032749740; Thu, 06 Feb 2020 15:45:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581032749; cv=none; d=google.com; s=arc-20160816; b=GFZ6I1NL+hvlG33SbG4hDpXBMFq6h9Z+HDLSWr1rxpK3E2rA79zQ5QVYRzgjFrQS6r 4kjU9c9LEqBHsn060gqa/iPuavGSIwIW+8oyMdrEFxex9Z8hLZ7clyBiMjCH6y4SsKq9 IahwYlK9nvZDpyLFhLu0WAQ92VnVLmQrwzBlnqzD9CO1MOn57ds9DX6sj7LH+YyYesNR +Ur85n9eN4VEtqriVlCcjGlC6UEZmvRKom/vHUIjJeo3XJWVMDasWKArbu1fWKsLShln huYpxEuDssm+klIfk9Ebp5lg4doaLQ6T+Y8kzPw1SanKgfxTMWGKUHVpus8HXKg/O+hB jfww== 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:reply-to:message-id :subject:cc:to:from:date; bh=OHEBz0phlkcgx/0gM4EIc7SRlvsFhqiSQJOcSNAUSgk=; b=BOatbMLX1Hk68fk7qwuAtCzQ6P3Z2Iq+BvJSHDR6IUakYl0bo/lRF25ISCYIoIPlYT nMrcasr9K3+rS2NCQk19ymyH49hAmrdfg+rl6Gvi2Vwsmrhu+ehbIc4z4C2WD09ZbYbU 0j7ueSsgHRTZ8cIvzKExcpd1seu/24KRNuSOskAActCFTX3WMgcDQZWo67L1dTzlAsHR Mp46mkKB9Bsl/K3pcpVM50MhAxAec4SEjITxf9F5a8y57LCeHBtbQleeBl9QaFNU1Y7R 7XWSFCIUKkFDF3nnRTe8RuQBLGS5h0yqyIywKSTFADp/1SO/MiVFj4Z+VPujqc5PAZe6 CJXQ== 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=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f17si632392oto.85.2020.02.06.15.45.32; Thu, 06 Feb 2020 15:45: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; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727195AbgBFXo1 (ORCPT + 99 others); Thu, 6 Feb 2020 18:44:27 -0500 Received: from mga11.intel.com ([192.55.52.93]:59739 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726543AbgBFXo0 (ORCPT ); Thu, 6 Feb 2020 18:44:26 -0500 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 fmsmga102.fm.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) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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