[2/2] mm/page_alloc: add some comments to explain the possible hole in __pageblock_pfn_to_page()
Message ID | 02defcbe9d7a797a2257e5f6a28ff7ea78e394e5.1682158312.git.baolin.wang@linux.alibaba.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp1617829vqo; Sat, 22 Apr 2023 03:17:45 -0700 (PDT) X-Google-Smtp-Source: AKy350brUD503VIPt5leblQqxnfluzSlyAQIpxgn4cCm8416iPPMj9WNpPNGWTDciFXDPUT/lb8X X-Received: by 2002:a05:6a21:100e:b0:f1:8f7:eeb5 with SMTP id nk14-20020a056a21100e00b000f108f7eeb5mr8647911pzb.60.1682158664698; Sat, 22 Apr 2023 03:17:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1682158664; cv=none; d=google.com; s=arc-20160816; b=07i4gYk1e3khTKLkbH6t+/qdyeVj8dYZ5QS81gufM2m5BRAzEvN0AM6lRgUQHl7CFt lFBIxBrEVb46VHa6XeI2akCjefP/pkCwulh7+qtM1TwVEPh5GsislaA+DQppPsA0fA51 Oslz00ul5ZgANz2PFQAWvwTYUBGgRpcryhNN6pYKQeNTz5cvAfZF0yyszrQjM+PTTy5h PGS7LP4FWgsYtcsJtcmg/5G8UqeC9DkvucIsWTZSTYDCB8kHEShrmlCR28iAcWWHHPrm i52FBgQHluHzU2ZccS/8r6KZQ/FuLmIN5g/9Mf2zWPUcAWrR/4/8Ig5VbXZCcNysMU4f lNmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=YcLa0KSM8wD3Sx5aB5eDsccrbn1dqKcpDuLQ6Mqt8Ks=; b=W0xdwEjEoZHxl135qcnDcHgo99QJYBiS3oQSwspg/6J4Gpn+lBughrhu4hh28mByeY 3D+Ed9a9O659MCzeJl1eVHX21Ii62ePSftfpidV72Tcp4kdMBlfSV2uUgjRF/+jUJasq 1DU0TwE0n2raEGjQHx0DChsEJ6+Fc5eKDoYNfF+qXdx9ndh3avkD/AC0MRH1F2GwOxO2 xWOumshhEqv/tQylkqOQ0Ww1gTSqSgBnmjj+i9sduH7MH1N4dpiEHpFtxiEkdw3GW8Op /9hhXUJKgljnB018Awlm297cl+vX4zRuCzBP9nPKx5rQI4fvyNGmxkAuOEzmVwiYG+B5 bZKw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id a3-20020a63e843000000b0051ba9b9c3f3si2622993pgk.321.2023.04.22.03.17.29; Sat, 22 Apr 2023 03:17:44 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229810AbjDVKQJ (ORCPT <rfc822;cjcooper78@gmail.com> + 99 others); Sat, 22 Apr 2023 06:16:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42388 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229684AbjDVKPl (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 22 Apr 2023 06:15:41 -0400 Received: from out30-131.freemail.mail.aliyun.com (out30-131.freemail.mail.aliyun.com [115.124.30.131]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AD7601FEB for <linux-kernel@vger.kernel.org>; Sat, 22 Apr 2023 03:15:32 -0700 (PDT) X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R691e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046059;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=9;SR=0;TI=SMTPD_---0VgfnVKn_1682158528; Received: from localhost(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0VgfnVKn_1682158528) by smtp.aliyun-inc.com; Sat, 22 Apr 2023 18:15:29 +0800 From: Baolin Wang <baolin.wang@linux.alibaba.com> To: akpm@linux-foundation.org Cc: ying.huang@intel.com, mgorman@techsingularity.net, vbabka@suse.cz, mhocko@suse.com, david@redhat.com, baolin.wang@linux.alibaba.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH 2/2] mm/page_alloc: add some comments to explain the possible hole in __pageblock_pfn_to_page() Date: Sat, 22 Apr 2023 18:15:18 +0800 Message-Id: <02defcbe9d7a797a2257e5f6a28ff7ea78e394e5.1682158312.git.baolin.wang@linux.alibaba.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <c2eee65ecd15779721af85c9ff109a35345b52d4.1682158312.git.baolin.wang@linux.alibaba.com> References: <c2eee65ecd15779721af85c9ff109a35345b52d4.1682158312.git.baolin.wang@linux.alibaba.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-9.9 required=5.0 tests=BAYES_00, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE,UNPARSEABLE_RELAY, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1763871203526823343?= X-GMAIL-MSGID: =?utf-8?q?1763871203526823343?= |
Series |
[1/2] mm/page_alloc: drop the unnecessary pfn_valid() for start pfn
|
|
Commit Message
Baolin Wang
April 22, 2023, 10:15 a.m. UTC
Now the __pageblock_pfn_to_page() is used by set_zone_contiguous(), which
checks whether the given zone contains holes, and uses pfn_to_online_page()
to validate if the start pfn is online and valid, as well as using pfn_valid()
to validate the end pfn.
However, though the start pfn of a pageblock is valid, it can not always
guarantee the end pfn of the pageblock is also valid (may be holes) in some
cases. For example, if the pageblock order is MAX_ORDER - 1, which will fall
into 2 sub-sections, and the end pfn of the pageblock may be hole even though
the start pfn is online and valid.
This did not break anything until now, but the zone continuous is fragile
in this possible scenario. So as previous discussion[1], it is better to
add some comments to explain this possible issue in case there are some
future pfn walkers that rely on this.
[1] https://lore.kernel.org/all/87r0sdsmr6.fsf@yhuang6-desk2.ccr.corp.intel.com/
Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
---
mm/page_alloc.c | 8 ++++++++
1 file changed, 8 insertions(+)
Comments
Baolin Wang <baolin.wang@linux.alibaba.com> writes: > Now the __pageblock_pfn_to_page() is used by set_zone_contiguous(), which > checks whether the given zone contains holes, and uses pfn_to_online_page() > to validate if the start pfn is online and valid, as well as using pfn_valid() > to validate the end pfn. > > However, though the start pfn of a pageblock is valid, it can not always > guarantee the end pfn of the pageblock is also valid (may be holes) in some > cases. For example, if the pageblock order is MAX_ORDER - 1, which will fall > into 2 sub-sections, and the end pfn of the pageblock may be hole even though > the start pfn is online and valid. > > This did not break anything until now, but the zone continuous is fragile > in this possible scenario. So as previous discussion[1], it is better to > add some comments to explain this possible issue in case there are some > future pfn walkers that rely on this. > > [1] https://lore.kernel.org/all/87r0sdsmr6.fsf@yhuang6-desk2.ccr.corp.intel.com/ > > Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com> > --- > mm/page_alloc.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 6457b64fe562..dc4005b32ae0 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -1502,6 +1502,14 @@ void __free_pages_core(struct page *page, unsigned int order) > * interleaving within a single pageblock. It is therefore sufficient to check > * the first and last page of a pageblock and avoid checking each individual > * page in a pageblock. > + * > + * Note: if the start pfn of a pageblock is valid, but it can not always guarantee > + * the end pfn of the pageblock is also valid (may be holes) in some cases. For "valid" sounds confusing here. pfn_valid() is true, but the pfn is considered invalid at some degree. How about the following? Note: the function may return non-NULL even if the end pfn of a pageblock is in a memory hole in some situations. For > + * example, if the pageblock order is MAX_ORDER - 1, which will fall into 2 > + * sub-sections, and the end pfn of the pageblock may be hole even though the > + * start pfn is online and valid. This did not break anything until now, but be > + * careful this possible issue when checking if the whole pfns are valid of a ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ whether all pfns of a pageblock are valid. ? > + * pageblock. > */ > struct page *__pageblock_pfn_to_page(unsigned long start_pfn, > unsigned long end_pfn, struct zone *zone) My English is poor. So, feel free to ignore the comments. Best Regards, Huang, Ying
On 4/23/2023 9:13 AM, Huang, Ying wrote: > Baolin Wang <baolin.wang@linux.alibaba.com> writes: > >> Now the __pageblock_pfn_to_page() is used by set_zone_contiguous(), which >> checks whether the given zone contains holes, and uses pfn_to_online_page() >> to validate if the start pfn is online and valid, as well as using pfn_valid() >> to validate the end pfn. >> >> However, though the start pfn of a pageblock is valid, it can not always >> guarantee the end pfn of the pageblock is also valid (may be holes) in some >> cases. For example, if the pageblock order is MAX_ORDER - 1, which will fall >> into 2 sub-sections, and the end pfn of the pageblock may be hole even though >> the start pfn is online and valid. >> >> This did not break anything until now, but the zone continuous is fragile >> in this possible scenario. So as previous discussion[1], it is better to >> add some comments to explain this possible issue in case there are some >> future pfn walkers that rely on this. >> >> [1] https://lore.kernel.org/all/87r0sdsmr6.fsf@yhuang6-desk2.ccr.corp.intel.com/ >> >> Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com> >> --- >> mm/page_alloc.c | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index 6457b64fe562..dc4005b32ae0 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -1502,6 +1502,14 @@ void __free_pages_core(struct page *page, unsigned int order) >> * interleaving within a single pageblock. It is therefore sufficient to check >> * the first and last page of a pageblock and avoid checking each individual >> * page in a pageblock. >> + * >> + * Note: if the start pfn of a pageblock is valid, but it can not always guarantee >> + * the end pfn of the pageblock is also valid (may be holes) in some cases. For > > "valid" sounds confusing here. pfn_valid() is true, but the pfn is > considered invalid at some degree. How about the following? > > Note: the function may return non-NULL even if the end pfn of a > pageblock is in a memory hole in some situations. For > >> + * example, if the pageblock order is MAX_ORDER - 1, which will fall into 2 >> + * sub-sections, and the end pfn of the pageblock may be hole even though the >> + * start pfn is online and valid. This did not break anything until now, but be >> + * careful this possible issue when checking if the whole pfns are valid of a > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > whether all pfns of a pageblock are valid. ? > >> + * pageblock. >> */ >> struct page *__pageblock_pfn_to_page(unsigned long start_pfn, >> unsigned long end_pfn, struct zone *zone) > > My English is poor. So, feel free to ignore the comments. Better than me:) . Will do in next version. Thanks.
Hi, On Sat, Apr 22, 2023 at 06:15:18PM +0800, Baolin Wang wrote: > Now the __pageblock_pfn_to_page() is used by set_zone_contiguous(), which > checks whether the given zone contains holes, and uses pfn_to_online_page() > to validate if the start pfn is online and valid, as well as using pfn_valid() > to validate the end pfn. > > However, though the start pfn of a pageblock is valid, it can not always > guarantee the end pfn of the pageblock is also valid (may be holes) in some > cases. For example, if the pageblock order is MAX_ORDER - 1, which will fall Nit: in the current mm tree the default pageblock order is MAX_ORDER. > into 2 sub-sections, and the end pfn of the pageblock may be hole even though > the start pfn is online and valid. > > This did not break anything until now, but the zone continuous is fragile > in this possible scenario. So as previous discussion[1], it is better to > add some comments to explain this possible issue in case there are some > future pfn walkers that rely on this. > > [1] https://lore.kernel.org/all/87r0sdsmr6.fsf@yhuang6-desk2.ccr.corp.intel.com/ > > Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com> > --- > mm/page_alloc.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 6457b64fe562..dc4005b32ae0 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -1502,6 +1502,14 @@ void __free_pages_core(struct page *page, unsigned int order) > * interleaving within a single pageblock. It is therefore sufficient to check > * the first and last page of a pageblock and avoid checking each individual > * page in a pageblock. > + * > + * Note: if the start pfn of a pageblock is valid, but it can not always guarantee > + * the end pfn of the pageblock is also valid (may be holes) in some cases. For > + * example, if the pageblock order is MAX_ORDER - 1, which will fall into 2 > + * sub-sections, and the end pfn of the pageblock may be hole even though the > + * start pfn is online and valid. This did not break anything until now, but be > + * careful this possible issue when checking if the whole pfns are valid of a careful about ... > + * pageblock. > */ > struct page *__pageblock_pfn_to_page(unsigned long start_pfn, > unsigned long end_pfn, struct zone *zone) > -- > 2.27.0 > >
On 4/23/2023 1:19 PM, Mike Rapoport wrote: > Hi, > > On Sat, Apr 22, 2023 at 06:15:18PM +0800, Baolin Wang wrote: >> Now the __pageblock_pfn_to_page() is used by set_zone_contiguous(), which >> checks whether the given zone contains holes, and uses pfn_to_online_page() >> to validate if the start pfn is online and valid, as well as using pfn_valid() >> to validate the end pfn. >> >> However, though the start pfn of a pageblock is valid, it can not always >> guarantee the end pfn of the pageblock is also valid (may be holes) in some >> cases. For example, if the pageblock order is MAX_ORDER - 1, which will fall > > Nit: in the current mm tree the default pageblock order is MAX_ORDER. Ah, yes, will change in next version. > >> into 2 sub-sections, and the end pfn of the pageblock may be hole even though >> the start pfn is online and valid. >> >> This did not break anything until now, but the zone continuous is fragile >> in this possible scenario. So as previous discussion[1], it is better to >> add some comments to explain this possible issue in case there are some >> future pfn walkers that rely on this. >> >> [1] https://lore.kernel.org/all/87r0sdsmr6.fsf@yhuang6-desk2.ccr.corp.intel.com/ >> >> Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com> >> --- >> mm/page_alloc.c | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index 6457b64fe562..dc4005b32ae0 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -1502,6 +1502,14 @@ void __free_pages_core(struct page *page, unsigned int order) >> * interleaving within a single pageblock. It is therefore sufficient to check >> * the first and last page of a pageblock and avoid checking each individual >> * page in a pageblock. >> + * >> + * Note: if the start pfn of a pageblock is valid, but it can not always guarantee >> + * the end pfn of the pageblock is also valid (may be holes) in some cases. For >> + * example, if the pageblock order is MAX_ORDER - 1, which will fall into 2 >> + * sub-sections, and the end pfn of the pageblock may be hole even though the >> + * start pfn is online and valid. This did not break anything until now, but be >> + * careful this possible issue when checking if the whole pfns are valid of a > > careful about ... OK. Thanks for reviewing.
diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 6457b64fe562..dc4005b32ae0 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -1502,6 +1502,14 @@ void __free_pages_core(struct page *page, unsigned int order) * interleaving within a single pageblock. It is therefore sufficient to check * the first and last page of a pageblock and avoid checking each individual * page in a pageblock. + * + * Note: if the start pfn of a pageblock is valid, but it can not always guarantee + * the end pfn of the pageblock is also valid (may be holes) in some cases. For + * example, if the pageblock order is MAX_ORDER - 1, which will fall into 2 + * sub-sections, and the end pfn of the pageblock may be hole even though the + * start pfn is online and valid. This did not break anything until now, but be + * careful this possible issue when checking if the whole pfns are valid of a + * pageblock. */ struct page *__pageblock_pfn_to_page(unsigned long start_pfn, unsigned long end_pfn, struct zone *zone)