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 3486EEB64D8 for ; Wed, 21 Jun 2023 10:00:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C5A7A8D0002; Wed, 21 Jun 2023 06:00:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C0A5C8D0001; Wed, 21 Jun 2023 06:00:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AD38D8D0002; Wed, 21 Jun 2023 06:00:37 -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 9FE908D0001 for ; Wed, 21 Jun 2023 06:00:37 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 76637120916 for ; Wed, 21 Jun 2023 10:00:37 +0000 (UTC) X-FDA: 80926310514.18.D89B1BD Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf24.hostedemail.com (Postfix) with ESMTP id AE69D180021 for ; Wed, 21 Jun 2023 10:00:33 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf24.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687341635; 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=FKFhKNjamweV+4Zm20b/hKCsVBAUUGYupWQRUEVbHbc=; b=J8CU0f7axymp2+LL27n7wSBYjtIT0rbsrJXQgzBIBjtma2iZbcDvZbPabwhXIQ/1kunfGq cVrMqNav1nYrp3cPFvoaWUE0Ci+XH/2ZdkwB9PIA3vtZTRAK4o3VcozPzoBJzNiKLfIddW G/RPb9XtNGVoFNUf31TJa3Nxe/yKof8= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf24.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687341635; a=rsa-sha256; cv=none; b=7YBw0H0RE32b+cIV1DHpWZN28WqKvx3p77XAtaUWrermOQantCQif1pBxQKBRIzRWZh8R2 5YiJ/8HTV2200WYNftIDuo41b8H26ORdin2GzTsUGoesau+kuy2x3QncjIAdhyXl5/PpXn ZzJ5xYmM35A48mghGU5asWfGqqxqe4Q= Received: from dggpemm100001.china.huawei.com (unknown [172.30.72.55]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4QmJsG4D2czqTl7; Wed, 21 Jun 2023 18:00:18 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemm100001.china.huawei.com (7.185.36.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.27; Wed, 21 Jun 2023 18:00:26 +0800 Message-ID: <2fb1f6dd-afea-caf5-a94b-6915b21258a4@huawei.com> Date: Wed, 21 Jun 2023 18:00:25 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: [PATCH v3] mm/min_free_kbytes: modify min_free_kbytes calculation rules Content-Language: en-US To: liuq , CC: , , , mawupeng 00564683 , Mel Gorman References: <20230621092048.5242-1-liuq131@chinatelecom.cn> From: Kefeng Wang In-Reply-To: <20230621092048.5242-1-liuq131@chinatelecom.cn> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemm100001.china.huawei.com (7.185.36.93) X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: AE69D180021 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: e7wx5dqd57jatfqi45zh6b5kh69w4wo6 X-HE-Tag: 1687341633-545769 X-HE-Meta: U2FsdGVkX19PGmiUHnMY3XC3iU2Vi5DpxDiWysZbqO5thwH5z+xp2jTZDHLQ6CT2l/+jcxaEgecrTlNsLqjvBzymumYHzUqYYE6+2AcWP/gfddty5g+n9POeI52b0lfizqhBYGUxeUroZPRanZOY8LO2tEPtsoBc1oGUoladWQkf7FVxXcpXMYGQ0VbHk+pwVdpgBGFdJnds9VvozXnmw6q7lIC1JfjRHc94iXAvijyWsaVrPZknnKdajWFhd8lwpb4flsAQk1ByOmGk66jfXHwm63my17GWHLJb+0tuLUkF4isyUANsQbgtIxKQ563XRTjjvHNNlEEVunLhTIrce6nzMMA//J4RXPfNWlzDu2N2/eBxvqb8zC3/m/+L+W0OX2sFkjVBy67qi8QJMnYK7T0iX8KK8yB2pS1pMmkBlsLZOy29fusbt+pvDwnlheZF4Pf52apuB4H8rC0dFFxKGaBeq8arX73Cxz1RFl4bMEu0bYU0XNBahQhl3n1dsyDF2bAnmXdD8rs8ZNFxtdpBrTQtmpuTA8Cc/a/kyZCqb0g2nvB9yHYXMp18npGdYA/ssMQYbtH/lD+LeioP9Htvg0TCL9H/LL5kk3ndWIXCtUlr9vTR0wwlklXv8U5PXhLlKAQDPDnfrOUsd2wgvOrGNSjgKgbZjEH9jcI+6m2l8yNn3K4oNeRkuZC4snJ2yaTnMTZKlyTcItxHnCs1FAiJegX9CTD/b5/qUZEmaE/RH/11+1NCsBrkYcw25PC73zUhb8EUlO492Y/weYlx/8HPX/TXmNQN0C9TrEzwLo4Z4SObmbFjTW8H/unPN1mYmW719qZWtP3nEPHlHMtAfFIozZqvHbmNYm8xf150LHKT+otpNAGoBL/in+B7iG5B0EpDTQ4dZqSgSVjO2ZO2ezGG1eXiMCOXwQr7nGqDjqq8cICoGoiqCLWC72o+Ry8rLZORHCK7Sf8ZWuzQdTGKR0u vWeJJbEL jgY0VZLRewqivelszsoN7nfjGQP5YMYtP92vPNtVRYuhCEJZoFkJEnVSTj3hPI4RQP4nV1BLdTIckeGS1L/o/DSevq8bh9uxRf9EEBAiPfCO0R4m8b4CS4bwe+5/xN41mdCVYwL1e+OOw5merdYA2Zv042OScYPhruEZg9XwKyiSWHFUy5+wqFgb+Lm82hs5WOEvkfbNNc9mNVyQmgAcdYO/Mgfs1WcOolqKfe5r15uGX9jIfkVLlcoWEvJoBoJxpftXAleMLndCnX0Y= 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: Hi Liuq, On 2023/6/21 17:20, liuq wrote: > The current calculation of min_free_kbytes only uses ZONE_DMA and > ZONE_NORMAL pages,but the ZONE_MOVABLE zone->_watermark[WMARK_MIN] > will also divide part of min_free_kbytes.This will cause the min > watermark of ZONE_NORMAL to be too small in the presence of ZONE_MOVEABLE. > > __GFP_HIGH and PF_MEMALLOC allocations usually don't need movable > zone pages, so just like ZONE_HIGHMEM, cap pages_min to a small > value in __setup_per_zone_wmarks. > > On my testing machine with 16GB of memory (transparent hugepage is > turned off by default, and movablecore=12G is configured) > The following is a comparative test data of watermark_min > > no patch add patch > ZONE_DMA 1 8 > ZONE_DMA32 151 709 > ZONE_NORMAL 233 1113 > ZONE_MOVABLE 1434 128 > min_free_kbytes 7288 7326 > We see this issue and do the same change[1], and we add a per zone watermark configuration too, but both of them is not accepted, let's add Mel and wupeng to see more comments. [1]https://lore.kernel.org/linux-mm/20220905032858.1462927-1-mawupeng1@huawei.com/ > Signed-off-by: liuq > --- > 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 47421bedc12b..590ed8725e09 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -6362,9 +6362,9 @@ static void __setup_per_zone_wmarks(void) > struct zone *zone; > unsigned long flags; > > - /* Calculate total number of !ZONE_HIGHMEM pages */ > + /* Calculate total number of !ZONE_HIGHMEM and !ZONE_MOVABLE pages */ > for_each_zone(zone) { > - if (!is_highmem(zone)) > + if (!is_highmem(zone) && zone_idx(zone) != ZONE_MOVABLE) > lowmem_pages += zone_managed_pages(zone); > } > > @@ -6374,15 +6374,15 @@ static void __setup_per_zone_wmarks(void) > spin_lock_irqsave(&zone->lock, flags); > tmp = (u64)pages_min * zone_managed_pages(zone); > do_div(tmp, lowmem_pages); > - if (is_highmem(zone)) { > + if (is_highmem(zone) || zone_idx(zone) == ZONE_MOVABLE) { > /* > * __GFP_HIGH and PF_MEMALLOC allocations usually don't > - * need highmem pages, so cap pages_min to a small > - * value here. > + * need highmem and movable zones pages, so cap pages_min > + * to a small value here. > * > * The WMARK_HIGH-WMARK_LOW and (WMARK_LOW-WMARK_MIN) > * deltas control async page reclaim, and so should > - * not be capped for highmem. > + * not be capped for highmem and movable zones. > */ > unsigned long min_pages; >