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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 85CDDC77B76 for ; Sun, 23 Apr 2023 06:00:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B936E6B0072; Sun, 23 Apr 2023 02:00:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B44156B0074; Sun, 23 Apr 2023 02:00:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A59046B0075; Sun, 23 Apr 2023 02:00:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 946AD6B0072 for ; Sun, 23 Apr 2023 02:00:15 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2A107801CB for ; Sun, 23 Apr 2023 06:00:15 +0000 (UTC) X-FDA: 80711605590.29.1AE16CF Received: from out30-131.freemail.mail.aliyun.com (out30-131.freemail.mail.aliyun.com [115.124.30.131]) by imf25.hostedemail.com (Postfix) with ESMTP id 628C5A001B for ; Sun, 23 Apr 2023 06:00:11 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.131 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682229613; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=p0CJR2cT7sWkC7ZIMExEmuqbeXEtDN572E9S7YRFVqA=; b=eCv5OchRcPIp9HEGIBuv2ahzoMQXG+MXdjy6fKJirJTu7yubmsCqivvytT3Jk5Rbq8mJkP SZwdxfwB+awt5clIsJg5awvhPfy3GmdgXsQK4nv73WssHN+3DQK1kyZ8cHa97Y6KQ2em9f zYM49QeIx3guatGL403WEaq0RXUUpcU= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; spf=pass (imf25.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.131 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682229613; a=rsa-sha256; cv=none; b=b7uKhB6Mfbu8wK4dwGTHW7YlTNHwWzuATNjnkY/XkTnu96fELCtd0tH2ZBK5/tGrZTd5Lh 5wfKr47KkMo6OCXr2t+LgtqGs1ipGMLZ1euWG4mJgNjRqxal/rczoqK6SVHROS1+lWoMVP +Ib8O7V/XsGxf7em0xXl1z+X9CKYW7Y= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R121e4;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_---0VgiUM0a_1682229605; Received: from 30.97.48.67(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0VgiUM0a_1682229605) by smtp.aliyun-inc.com; Sun, 23 Apr 2023 14:00:06 +0800 Message-ID: <9b9f6247-8428-e3ee-18e5-0dda59bbd5e5@linux.alibaba.com> Date: Sun, 23 Apr 2023 14:00:05 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH 2/2] mm/page_alloc: add some comments to explain the possible hole in __pageblock_pfn_to_page() To: Mike Rapoport Cc: akpm@linux-foundation.org, ying.huang@intel.com, mgorman@techsingularity.net, vbabka@suse.cz, mhocko@suse.com, david@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <02defcbe9d7a797a2257e5f6a28ff7ea78e394e5.1682158312.git.baolin.wang@linux.alibaba.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Stat-Signature: onsmg34dc8sxqwybhmu3c3zoaooese85 X-Rspam-User: X-Rspamd-Queue-Id: 628C5A001B X-Rspamd-Server: rspam06 X-HE-Tag: 1682229611-562225 X-HE-Meta: U2FsdGVkX18jlg4KTX/PrbS2xROQdCqxWa6czVWfU+bdUQW/psSqo+iW2KPyRMZFN6yMhlntwrct5ok7X+Le1dwwMtqdHPfR7qC5wEngn9tMAlUaVg8OjkfR0Lf417uLUNtWXUmBbKSsw7YLfjMo0a8+CKlsCuL93IEE+uZ6PXBefn4di3w7tinc1hH8oVdN75gpisMPDz8oznDZUnCXEQafebdgzhoXZw3jDXQH7KO9yifVPAr0zngPHUOjuKIERwEqblTRtejtqGnMNUJPJ2Ch1aJauonDpb0RldhqsIg9h/sr0WvTdSeK1nkephEUExIy+y/tTAjIqHxZb1a/HYmey/HJ9wOurLkJB3XVS2JbeKM4bBSDvZJIFdFkkhwT5+FMRdeKk7ygVOmXwRkXk7IVT/h7ywl+ODbRV5liMGVb8Nbk8fStH5AHp/s0c5NmXh7ar+ta5LImNPqGn8cQeGavanwxbGbLy22Y/IxOlCw+s+8WtfEtMOpiKAc1N7QvuQ9cH+c360ejmuoCuzBfqDK1em7bAjvPmzM2KVstBs4N8jht7oCzbeJ1S83pC97yYAnOH31tcUg9lUCqMpVG/nnECutDR93zOIsB73ylyT6NewCL8Zmjnd5cxK53URcE3g9/Rrp9y2Nnj5YjdbEIG+n1rJjEktyZbruzwvEABFoy7eydQLU1TCfp1uUvYT3+36/6gUfVSAGv3Ww3x5T5XbbclWs91IR64QHBtAFavmpTpKYIOTsUwVcDW2suOK+iTo7MCOq3lKqChdmxXIChCW8zUZ3HLvWEgNFzMwNLFYga4bO6hLwEh3p41jLaARV9WeXuNxtcviGuHFPmJvwCEO5tovdBdQg6hnu2kZGL5LgcUlloF5hukmwX70vdBYbxz6kDQ/bCk468DdiMuuN/l0w5KYEtkIKsb+byheFT/sUcRd+nJcAugOHfhS/L/FGmmuhFfsDC5Ho7hAVeB7Q 2Jf8CY2V AgIMF5WhfUlNoR4pzgZo/CJ2gudKzF3E3JqioiscvP1Vhw9lmihTXKb+7nYHf5S1LRdma2FqIJv6v/utb5mQYGvScQG008M1w0PpGiwc3gApUxrTf/49y70TC3EYBsPUkvFKv8wdqVA/yVq08GiAGKIocGAnKXIg1UNOYvyv0UbIJPR2Zr914fOJd05gXfYiIm4A8+Kvc+yQx6nqX1LaP5qfzho5F9UeAvXGsxTgKC+/JRyYsZV4alSet/aiCCa2Bt8Pgbe0PMym/P0Q= 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 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 >> --- >> 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.