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 23B1EEB64D7 for ; Wed, 21 Jun 2023 14:30:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F7978D0003; Wed, 21 Jun 2023 10:30:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A7778D0002; Wed, 21 Jun 2023 10:30:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 821128D0003; Wed, 21 Jun 2023 10:30:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 6E7208D0002 for ; Wed, 21 Jun 2023 10:30:52 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 1E0CE408CA for ; Wed, 21 Jun 2023 14:30:52 +0000 (UTC) X-FDA: 80926991544.29.280D37E Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.220]) by imf10.hostedemail.com (Postfix) with ESMTP id 28625C0002 for ; Wed, 21 Jun 2023 14:30:29 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of liuq131@chinatelecom.cn designates 42.123.76.220 as permitted sender) smtp.mailfrom=liuq131@chinatelecom.cn; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687357834; a=rsa-sha256; cv=none; b=3VaOl9Xvyd3uLnnyTEwJwDpmxh1XFIvpci/BhAI/AjCA9vxsaa++mmHqEhZeV+HP1FcsOD dgyAG06H9vkPl2YFbRPGZUIW+7sD+fQoWcXLdov3x6sw7LKGNeCVwcdkMKrcuXWu7vcX2A CPHcwJxO2g0RH8nweF4jVRZDAqDy92k= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of liuq131@chinatelecom.cn designates 42.123.76.220 as permitted sender) smtp.mailfrom=liuq131@chinatelecom.cn; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687357834; h=from:from:sender: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: in-reply-to:in-reply-to:references:references; bh=F3NOppKQJvdGqhJFqfEY4nux8E9UdIDwXDZW8TVWP10=; b=Cux6xEZeaTdBnX7ae8mXNj+P5uolZJksbPE5j0ZQdsU79NPQ23XYn+uLdSrbABy6Oe1sEY BpuKQWYDo3re9VC+h56tNlQKjMBI62dehMAliW4NrsT0klFzIjfxrrMBG5sEuLTOFcYZv7 CggWEoKiVXTC42zDSS68sfnTNx7tfF4= HMM_SOURCE_IP:172.18.0.48:56960.701018138 HMM_ATTACHE_NUM:0000 HMM_SOURCE_TYPE:SMTP Received: from clientip-111.9.1.183 (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with SMTP id 6787A2800A4; Wed, 21 Jun 2023 22:30:18 +0800 (CST) X-189-SAVE-TO-SEND: liuq131@chinatelecom.cn Received: from ([111.9.1.183]) by app0024 with ESMTP id b8fe9196ff4a4a419c7b9c59c0885133 for wangkefeng.wang@huawei.com; Wed, 21 Jun 2023 22:30:27 CST X-Transaction-ID: b8fe9196ff4a4a419c7b9c59c0885133 X-Real-From: liuq131@chinatelecom.cn X-Receive-IP: 111.9.1.183 X-MEDUSA-Status: 0 Content-Type: multipart/alternative; boundary="------------i3y9GHaUl8XQKOyPUh4TlQST" Message-ID: <9754c941-2260-f1e9-07f5-a2d3696ea4e9@chinatelecom.cn> Date: Wed, 21 Jun 2023 22:30:16 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [PATCH v3] mm/min_free_kbytes: modify min_free_kbytes calculation rules To: Kefeng Wang , akpm@linux-foundation.org Cc: ying.huang@intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, mawupeng 00564683 , Mel Gorman References: <20230621092048.5242-1-liuq131@chinatelecom.cn> <2fb1f6dd-afea-caf5-a94b-6915b21258a4@huawei.com> From: liuq In-Reply-To: <2fb1f6dd-afea-caf5-a94b-6915b21258a4@huawei.com> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 28625C0002 X-Stat-Signature: wm98krhb8gmkxumkdty8w8ak9zjouxzi X-HE-Tag: 1687357829-401568 X-HE-Meta: U2FsdGVkX19jJG8uXciF+bSRM/TlDxBzBHDi3EEMUBo1hNdmNSkAd+4T7BRjI7kQZ9diXeYiRUvIQUPjQhXBWGlFtzKiPwzrML+PYCtICM5W9XTXK3pAiOlQu8c1FNZmp2GPVO1A0c47ap5In6C2aWJU4E45aer0OnTOp9TyWkea9BMGcNB3VDV6SIJ+2vo0aX7pCq82khzJxRL4RbXhhQ0J7PGadvBrJ7Iq1DfKgaJZkDzcjqsRCNhXtuVw3Is7xTI+X22YNunGbNzYcMaCAS4bWR6Asi/NFQaTnZkKh0XlOqWzhOi7TYFN19I9kThKkkdaa0QIfInUoYaNNNMTYgPLuxhZEEYnUGSEoWLBahtIPrmJONyEqef3Pf8ewevQQUALjJD+N5bGbD/oEaozGhfdPgIG43xTw2BDpCgpbVfV506fJ7+9+L6SVxBXVMaYxzCimKI8oEiiZIq4Ij270+ZVxabSyz46Zf/UJjNBiWbV9rFh4gbtGksmEHJrYnp8+pDfjNPLEXL00wAQuFRwYS+thLd90Uj09BEKaKTA6WoxGOgeszGDk2FCdY0DEobIrH3Dtij6DBHOIw3UonzsD13K/M7DyfCOdd58iEUUbMGVQx/zyPZjzlBxikweL4HXCyiooFw1yK719lQAg3KOgHerqa65l5Y8b4C049fFi1ILdtru8C7Cv+K5UUf51cTOq2qXvRj9IQ2TtSOExEMqQjZMIFYlbOVrC7R0zfBNAUw3fxkc8ncXYd5HDbX9Xg2ptsRrdMOtgm4pX/NBiYcJb1feTBuHf0KRdJQEUKkzSEjt2nNwdIlX7L+1h3R9PBL3thgxlQKl5h6O6uykQRDecjpUy7EeRhMaGWe8Vc+zMusf/c2KfxQ5XiETihIIpSKqyZ3faBYGn9LuPijlLL8Hoq4HzBrsaXzSiPOpaz1Xue2any/l4iWqJg1RxzaHimusoFHCskAajzOYGdlu9OL julJJ7zl nzX2ekuXmI1efBJZ6A6D85PyJQYLFbuesRTyUiu0n3hjFcAWNpK7ZgGGdw9vjxRrjmhGRZEcjPhPosyd9eMApCIfPnJAINjHqRRs59I6Mf1rbvwybUPgpGMv9xR+iDS4MV85x0i0TENuHYJh+/vGQKhUbOgLqlOxNzPM53xEGFtA2DIJjiNC5GSCpfDD/XO5TMxoTQDdNz7S3x4Y2R7q6P+C6L7En2OKf7N2C661aAlTXAXb6tIqObCRRQxNoaNfJheK/0+jKaSR+yVDz5MGMpIx7lwIMTxjCSV0s77YNDzUpvKMo0HaLVHjtA/RGjm0mYv4Dw0Ypvv5LgFpqPeUChctj/sTAnIdtTGe3AWcHJN1G/jB352XIMBoG65T3sYAQnqoq00oNXe2147C9vE/GY8mp1oIOywA2S3zMxD6tSFFL0rDM7pFK8ah44w== X-Bogosity: Ham, tests=bogofilter, spamicity=0.014910, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: This is a multi-part message in MIME format. --------------i3y9GHaUl8XQKOyPUh4TlQST Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 在 2023/6/21 18:00, Kefeng Wang 写道: > 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/ > > Hi wupeng, Thank you for your reply. Actually, in my version 1, in the presence of ZONE_MOVABLE, the calculation of min_free_kbytes can be improved when the ZONE_MOVABLE pages were added to the lowmem_kbytes. However, whether the value of watermark_min should be maintained at high level is unclear. https://lore.kernel.org/all/20230609032552.218010-1-liuq131@chinatelecom.cn/#r Best Regards liuq >> 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; --------------i3y9GHaUl8XQKOyPUh4TlQST Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


在 2023/6/21 18:00, Kefeng Wang 写道:
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/

Hi wupeng,

Thank you for your reply. Actually, in my version 1, in the presence of ZONE_MOVABLE,

the calculation of min_free_kbytes can be improved when the ZONE_MOVABLE pages were added to the lowmem_kbytes.

However, whether the value of watermark_min should be maintained at high level is unclear.

https://lore.kernel.org/all/20230609032552.218010-1-liuq131@chinatelecom.cn/#r


Best Regards

liuq

Signed-off-by: liuq <liuq131@chinatelecom.cn>
---
  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;
 
--------------i3y9GHaUl8XQKOyPUh4TlQST--