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 0C398C41513 for ; Wed, 2 Aug 2023 01:11:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5F4CB28010C; Tue, 1 Aug 2023 21:11:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5A5272800C8; Tue, 1 Aug 2023 21:11:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4465B28010C; Tue, 1 Aug 2023 21:11:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 2F2D02800C8 for ; Tue, 1 Aug 2023 21:11:06 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 01E781C9B3D for ; Wed, 2 Aug 2023 01:11:05 +0000 (UTC) X-FDA: 81077385732.19.5B1F484 Received: from out30-99.freemail.mail.aliyun.com (out30-99.freemail.mail.aliyun.com [115.124.30.99]) by imf09.hostedemail.com (Postfix) with ESMTP id 3E79114000C for ; Wed, 2 Aug 2023 01:11:02 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=none; spf=pass (imf09.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.99 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=1690938664; a=rsa-sha256; cv=none; b=KU2pEnu98RsR4TaVJqG8yLADlZolMGstYQPkkJi8dlKVxMVWR7ne3jpYwmjS8ecvSQjhYJ TzooO+1VajdwZeyTapxGyVxaI+RXZjSP+6yxtUiUD4vcMLcXrC/ig8O+RRnEnT5o8Jy2Ba mveaqCTOC+dQItk+J3Qe25ZR4X7dYQo= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=none; spf=pass (imf09.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.99 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=1690938664; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=qg9L1Yw6ORIKFW2KFQrE/dZbKv0LSQYJ3EPEHLhiVSI=; b=CUmpvKLx+PMnYHLXZp6O5sGKxhW7Wp8zBRi7ZX6Mwqyn+ZozD82w3mvFR3V/L3uBLyFX0a WvoPhOv/iTvJYiEIGrCqZaSgcJomcZOtiUF7sy5dNxg3VIHdjl9l3n6F8aLgFm9+sqGcN5 Ad655Q4F45rcmYMdiZIkMificZTbrIM= X-Alimail-AntiSpam:AC=PASS;BC=-1|-1;BR=01201311R111e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046050;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=7;SR=0;TI=SMTPD_---0Vosmk5t_1690938657; Received: from 30.97.48.77(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0Vosmk5t_1690938657) by smtp.aliyun-inc.com; Wed, 02 Aug 2023 09:10:58 +0800 Message-ID: <0bb2bddf-a9e6-a285-da5a-27ac4e114c73@linux.alibaba.com> Date: Wed, 2 Aug 2023 09:11:25 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: [PATCH 1/8] mm/compaction: avoid missing last page block in section after skip offline sections To: Kemeng Shi , akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, mgorman@techsingularity.net, willy@infradead.org, david@redhat.com References: <20230728171037.2219226-1-shikemeng@huaweicloud.com> <20230728171037.2219226-2-shikemeng@huaweicloud.com> <6e76323f-a1cc-7d20-676e-4eccdbcf6b91@linux.alibaba.com> <9b207dbf-1652-4851-7c6e-16220d5f2f3b@huaweicloud.com> <6921ae7e-0c30-0934-168c-9480ca30108f@huaweicloud.com> <7b42d243-c62f-856e-2b8c-ba43528528f0@huaweicloud.com> <8b5a1ab4-56d6-cc6a-5213-6586e33a8fdd@huaweicloud.com> From: Baolin Wang In-Reply-To: <8b5a1ab4-56d6-cc6a-5213-6586e33a8fdd@huaweicloud.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 3E79114000C X-Stat-Signature: 54mkbesdoueybq5uj8384d9nsgtcjqhp X-HE-Tag: 1690938662-579801 X-HE-Meta: U2FsdGVkX1+UKAZ7fnnswSy0AEy0F+AmIJdx/ieaZzrxN+lVN1J3kLugAQqwlTqLMLq6D6rExPfpHglyIc2+jZxOnpq0jrnm2B7wKi1bWGWVie8/CxHStyhw4H4TFJVKB4oxP5wumV659D62HVWtX5QJ4/L60Y94hCQzWMIatio00853BtWsSLXtFDY2NWWmA7rKm1oBQi4RC2JIfegeLyim1L06MF0VE1FTCmw/FOE2MFD+aMCekVivKchwaU6qj6AptMVPgd6XHCd8928RaSQ/pXdWo2rPRaAc7KZ8oVODB75OVyU48IhJk3hLtyJlJeVSSDnK2aSp+hmqMw3R7M6NV8zIHaWOr3NA+sDybNKMLVQ/Wj3uM6W0XorWHD3uixeqlGaiThqDVpp2HEtzusjLJoQC/BmnFuCCMoZano9ljR0csw6Xaxwk8sKZZjkhhc2cg+nxDQmy/jlwsooVLKiOM5g2dFqPXYpbE7B4RBVu9A348EkvZ9s8T2KzdE3Vxjo//6K6F8LmVaDJG35oOKW9l5WMvOVDHG9dluWaDLbs93sExPRHBspvcNBWXph+ZdBTu/ceMSclO1GcDNVyF1n2dsWxa4YDhzO5wB1KIU48mkejFhE2XsXdBXmyupIm4YYE/qXYrRtRdz7XM0d6OPSai6be579RmnUMUGowabhnG03xx2/Y/CBIZ+dnygiOarQReWMSt0IOXTJTZmQYEfU50+DIVb/XBVuUixL23ZgZ8rHZlYVcR7kRzn0EqEOePV4S92D7gzrhkrS4ydxY/tFxPHUUcgAsSRgfTaOIhL4FXGsTNlVDd+FSNkLSsY2BMGPHtWBTqMw2B1pNZ8QtDK65KIWuxA4q2wj1JORFK2YK4NsnJm+ncQ/0iW44N898LZE6xIOTNjULQoK10Po/1T6+L5wajaXMIbMrawEtpAatMvO0d0tOawL//77M1RTOkKUESj7VlzlxUjAwmB5 TqwwSazr I+nuo5UHRM8Yc6PPSyE+utStTwfoCroVHc6cP5B1ilmhX/hckb/n8XWhdFjQfLKc+8V/lr5u8fKuX2IQd9zRNPJ1N26ZbA9SSyreCQT/DjJQ4ZmtULKdJj37yZSJgin7rFALFBcImXAma29M= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 8/1/2023 8:33 PM, Kemeng Shi wrote: > > > on 8/1/2023 5:32 PM, Baolin Wang wrote: >> >> >> On 8/1/2023 4:42 PM, Kemeng Shi wrote: >>> >>> >>> on 8/1/2023 4:01 PM, Baolin Wang wrote: >>>> >>>> >>>> On 8/1/2023 2:08 PM, Kemeng Shi wrote: >>>>> >>>>> >>>>> on 8/1/2023 11:53 AM, Baolin Wang wrote: >>>>>> >>>>>> >>>>>> On 8/1/2023 10:36 AM, Kemeng Shi wrote: >>>>>>> >>>>>>> >>>>>>> on 8/1/2023 10:18 AM, Kemeng Shi wrote: >>>>>>>> >>>>>>>> >>>>>>>> on 7/31/2023 8:01 PM, Baolin Wang wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/29/2023 1:10 AM, Kemeng Shi wrote: >>>>>>>>>> skip_offline_sections_reverse will return the last pfn in found online >>>>>>>>>> section. Then we set block_start_pfn to start of page block which >>>>>>>>>> contains the last pfn in section. Then we continue, move one page >>>>>>>>>> block forward and ignore the last page block in the online section. >>>>>>>>>> Make block_start_pfn point to first page block after online section to fix >>>>>>>>>> this: >>>>>>>>>> 1. make skip_offline_sections_reverse return end pfn of online section, >>>>>>>>>> i.e. pfn of page block after online section. >>>>>>>>>> 2. assign block_start_pfn with next_pfn. >>>>>>>>>> >>>>>>>>>> Fixes: f63224525309 ("mm: compaction: skip the memory hole rapidly when isolating free pages") >>>>>>>>>> Signed-off-by: Kemeng Shi >>>>>>>>>> --- >>>>>>>>>>      mm/compaction.c | 5 ++--- >>>>>>>>>>      1 file changed, 2 insertions(+), 3 deletions(-) >>>>>>>>>> >>>>>>>>>> diff --git a/mm/compaction.c b/mm/compaction.c >>>>>>>>>> index 9b7a0a69e19f..ce7841363b12 100644 >>>>>>>>>> --- a/mm/compaction.c >>>>>>>>>> +++ b/mm/compaction.c >>>>>>>>>> @@ -259,7 +259,7 @@ static unsigned long skip_offline_sections_reverse(unsigned long start_pfn) >>>>>>>>>>            while (start_nr-- > 0) { >>>>>>>>>>              if (online_section_nr(start_nr)) >>>>>>>>>> -            return section_nr_to_pfn(start_nr) + PAGES_PER_SECTION - 1; >>>>>>>>>> +            return section_nr_to_pfn(start_nr + 1); >>>>>>>>> >>>>>>>>> This is incorrect, you returned the start pfn of this section. >>>>>>>>> >>>>>>>>>>          } >>>>>>>>>>            return 0; >>>>>>>>>> @@ -1670,8 +1670,7 @@ static void isolate_freepages(struct compact_control *cc) >>>>>>>>>>                    next_pfn = skip_offline_sections_reverse(block_start_pfn); >>>>>>>>>>                  if (next_pfn) >>>>>>>>>> -                block_start_pfn = max(pageblock_start_pfn(next_pfn), >>>>>>>>>> -                              low_pfn); >>>>>>>>>> +                block_start_pfn = max(next_pfn, low_pfn); >>>>>>>>> >>>>>>>>> 'block_start_pfn' should be pageblock aligned. If the 'next_pfn' is not pageblock-aligned (though this is not the common case), we should skip it. >>>>>>>>> >>>>>>>>> But if the 'next_pfn' is pageblock-aligned, yes, the commit f63224525309 still ignores the last pageblock, which is not right. So I think it should be: >>>>>>>>> block_start_pfn = pageblock_aligned(next_pfn) ? : pageblock_start_pfn(next_pfn); >>>>>>>>> block_start_pfn = max(block_start_pfn, low_pfn); >>>>>>>>> >>>>>>>> Hi Baolin, thanks for reply! As skip_offline_sections_reverse is based >>>>>>>> on skip_offline_sections. I make the assumption that section is pageblock >>>>>>>> aligned based on that we use section start from skip_offline_sections as >>>>>>>> block_start_fpn without align check. >>>>>>>> If section size is not pageblock aligned in real world, the pageblock aligned >>>>>>>> check should be added to skip_offline_sections and skip_offline_sections_reverse. >>>>>>>> If no one is against this, I will fix this in next version. THanks! >>>>>>>> >>>>>>> More information of aligment of section. For powerpc arch, we have SECTION_SIZE_BITS >>>>>>> with 24 while PAGE_SHIFT could be configured to 18. >>>>>>> Pageblock order is (18 + MAX_ORDER) which coule be 28 and is > SECTION_SZIE_BITS 24, >>>>>> >>>>>> The maximum pageblock order is MAX_ORDER. But after thinking more, I think return the start pfn or end pfn of a section is okay, and it should be aligned to a pageblock order IIUC. >>>>>> >>>>> Right, I mixed up the unit. >>>>>> So I think your change is good: >>>>>> + block_start_pfn = max(next_pfn, low_pfn); >>>>>> >>>>>> But in skip_offline_sections_reverse(), we should still return the last pfn of the online section. >>>>>> >>>>> Sure, then we should assign block_start_pfn with following change. Is this good to you? >>>>> -                block_start_pfn = max(pageblock_start_pfn(next_pfn), >>>>> +         block_start_pfn = max(pageblock_end_pfn(next_pfn), >>>>>                                 low_pfn); >>>> >>>> The last pfn of a section is already section aligned, so I think no need to call pageblock_end_pfn(), just like your original change is okay to me. >>>> block_start_pfn = max(next_pfn, low_pfn); >>>> >>>> >>> Um, if we keep "block_start_pfn = max(next_pfn, low_pfn);", should we also keep >>> returning end of section "section_nr_to_pfn(start_nr + 1);" instead of original last >>> pfn of the section "section_nr_to_pfn(start_nr) + PAGES_PER_SECTION - 1;" which seems >>> not aligned. >>> Assume SECTION_SIZE_BITS = 27, PAGE_SHIFT = 12, pageblock order = 10 >>> Last pfn of the section 0 is 0x7fff, end pfn of section 0 is 0x8000. The last pfn >>> is not aligned. >>> Please tell me if I misunderstand anything. Thanks! >> >> Ah, you are right, sorry for my bad arithmetic. Maybe we should return the end pfn (section_nr_to_pfn(start_nr) + PAGES_PER_SECTION) of the section in skip_offline_sections_reverse() with adding some comments to explain the return value like David suggested. Then we can remove the pageblock_end_pfn() in isolate_freepages(). >> >> > Sure, I will add comments in next version. As (section_nr_to_pfn(start_nr) + PAGES_PER_SECTION) > is = section_nr_to_pfn(start_nr + 1), I will keep the change to skip_offline_sections_reverse IMO, next section is confusing. We need return the end pfn of the current online section, and we usually get it by "section_nr_to_pfn(start_nr) + PAGES_PER_SECTION".