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=-15.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,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 023D5C47089 for ; Fri, 28 May 2021 02:20:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 786F560E08 for ; Fri, 28 May 2021 02:20:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 786F560E08 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E66878D0001; Thu, 27 May 2021 22:20:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E16A86B0071; Thu, 27 May 2021 22:20:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 98F1B8D0001; Thu, 27 May 2021 22:20:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0072.hostedemail.com [216.40.44.72]) by kanga.kvack.org (Postfix) with ESMTP id 571E16B0070 for ; Thu, 27 May 2021 22:20:43 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E469918077356 for ; Fri, 28 May 2021 02:20:42 +0000 (UTC) X-FDA: 78189036324.33.156EC6F Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf02.hostedemail.com (Postfix) with ESMTP id 8BACD41449C5 for ; Fri, 28 May 2021 02:20:37 +0000 (UTC) Received: from dggeml762-chm.china.huawei.com (unknown [172.30.72.56]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4FrpHn72rwzYnHq; Fri, 28 May 2021 10:17:57 +0800 (CST) Received: from dggpemm500009.china.huawei.com (7.185.36.225) by dggeml762-chm.china.huawei.com (10.1.199.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2176.2; Fri, 28 May 2021 10:20:38 +0800 Received: from [10.174.179.24] (10.174.179.24) by dggpemm500009.china.huawei.com (7.185.36.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.2; Fri, 28 May 2021 10:20:37 +0800 Subject: Re: [PATCH] mm/page_alloc: fix counting of managed_pages To: Baoquan He References: <20210527125707.3760259-1-liushixin2@huawei.com> <20210527234750.GB31898@MiWiFi-R3L-srv> CC: Andrew Morton , yangerkun , Kefeng Wang , , From: Liu Shixin Message-ID: <138221ad-5ae0-6db6-3572-b8324fb73fdd@huawei.com> Date: Fri, 28 May 2021 10:20:35 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20210527234750.GB31898@MiWiFi-R3L-srv> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.179.24] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpemm500009.china.huawei.com (7.185.36.225) X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 8BACD41449C5 Authentication-Results: imf02.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=huawei.com; spf=pass (imf02.hostedemail.com: domain of liushixin2@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=liushixin2@huawei.com X-Rspamd-Server: rspam04 X-Stat-Signature: uxxw4nu1c9az5ir9cia1pajgpz8dgx8z X-HE-Tag: 1622168437-51127 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 2021/5/28 7:47, Baoquan He wrote: > On 05/27/21 at 08:57pm, Liu Shixin wrote: >> The commit f63661566fad (mm/page_alloc.c: clear out zone->lowmem_reserve[] >> if the zone is empty) clear out zone->lowmem_reserve[] if zone is empty. >> But when zone is not empty and sysctl_lowmem_reserve_ratio[i] is set to zero, >> zone_managed_pages(zone) is not counted in the managed_pages either. This is >> inconsistent with the description of lowmen_reserve, so fix it. > Right, this is a good catch. Thanks for the fixing. > > Is it worth adding words in Documentation/admin-guide/sysctl/vm.rst > to notice this? > > Reviewed-by: Baoquan He > > Thanks > Baoquan With this patch, It's consistent with the calculation description of zone[i]'s protection[j]. This is implicit in the description so I don't think it's necessary to notice this. >> Fixes: f63661566fad ("mm/page_alloc.c: clear out zone->lowmem_reserve[] if the zone is empty") >> Reported-by: yangerkun >> Signed-off-by: Liu Shixin >> --- >> mm/page_alloc.c | 12 ++++++------ >> 1 file changed, 6 insertions(+), 6 deletions(-) >> >> diff --git a/mm/page_alloc.c b/mm/page_alloc.c >> index aaa1655cf682..49a2efce5a84 100644 >> --- a/mm/page_alloc.c >> +++ b/mm/page_alloc.c >> @@ -8061,14 +8061,14 @@ static void setup_per_zone_lowmem_reserve(void) >> unsigned long managed_pages = 0; >> >> for (j = i + 1; j < MAX_NR_ZONES; j++) { >> - if (clear) { >> - zone->lowmem_reserve[j] = 0; >> - } else { >> - struct zone *upper_zone = &pgdat->node_zones[j]; >> + struct zone *upper_zone = &pgdat->node_zones[j]; >> + >> + managed_pages += zone_managed_pages(upper_zone); >> >> - managed_pages += zone_managed_pages(upper_zone); >> + if (clear) >> + zone->lowmem_reserve[j] = 0; >> + else >> zone->lowmem_reserve[j] = managed_pages / ratio; >> - } >> } >> } >> } >> -- >> 2.18.0.huawei.25 >> >> > . >