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 3075AEB64D7 for ; Wed, 21 Jun 2023 08:17:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 750518D0002; Wed, 21 Jun 2023 04:17:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 700758D0001; Wed, 21 Jun 2023 04:17:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5EF6B8D0002; Wed, 21 Jun 2023 04:17:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 4D9AA8D0001 for ; Wed, 21 Jun 2023 04:17:32 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1D03B807EF for ; Wed, 21 Jun 2023 08:17:32 +0000 (UTC) X-FDA: 80926050744.23.B0FAF2B Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.226]) by imf08.hostedemail.com (Postfix) with ESMTP id E7A0716001A for ; Wed, 21 Jun 2023 08:17:28 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; spf=pass (imf08.hostedemail.com: domain of liuq131@chinatelecom.cn designates 42.123.76.226 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=1687335450; h=from:from:sender: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=XITeAkIe7u8XGBEteUbEbYQsQB9sgZW9AzEHLYcCNUo=; b=aoLUrzcOdavuamk7skWKpf1WUKQrZn/DjNyk8HXdohbcNXgqD3/8drJ0tfCyvS2vAvPwg7 q1WJNqm5xdNY8CX28peplTu4TCb9tcekyq08eMGSTWIiAP5zwDrvRH7K/+qiQ9ZeXudaX6 pJz2wgJtjgmCHwLWy9Dxvf/tJ0Irp8E= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687335450; a=rsa-sha256; cv=none; b=8MitwJlKvAJzTtr6n5UX0t+Jk2s7A+KQ+3ZqA0p6EB6bFKSrRbTKB+KuPdy3DBigN0xqwJ xeWMLsF61nfEcUXUYwSkMvDtM9777UyyxkHBIHUfaYyVs2M0peHQIWMNKM2GKFc6/LXwpn 93EiOSbMkGGe+Y4QRfCSXA0UQFPya6o= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; spf=pass (imf08.hostedemail.com: domain of liuq131@chinatelecom.cn designates 42.123.76.226 as permitted sender) smtp.mailfrom=liuq131@chinatelecom.cn; dmarc=none HMM_SOURCE_IP:172.18.0.188:45863.1358915370 HMM_ATTACHE_NUM:0000 HMM_SOURCE_TYPE:SMTP Received: from clientip-36.111.64.84 (unknown [172.18.0.188]) by chinatelecom.cn (HERMES) with SMTP id 347E62800BB; Wed, 21 Jun 2023 16:17:22 +0800 (CST) X-189-SAVE-TO-SEND: liuq131@chinatelecom.cn Received: from ([36.111.64.84]) by app0023 with ESMTP id 6ca4e00d18f54c93bb51d24ce130bd1e for akpm@linux-foundation.org; Wed, 21 Jun 2023 16:17:25 CST X-Transaction-ID: 6ca4e00d18f54c93bb51d24ce130bd1e X-Real-From: liuq131@chinatelecom.cn X-Receive-IP: 36.111.64.84 X-MEDUSA-Status: 0 Message-ID: <653da4af-f999-690c-569d-bfee173eeffb@chinatelecom.cn> Date: Wed, 21 Jun 2023 16:17:22 +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 v2] mm/min_free_kbytes: modify min_free_kbytes calculation rules To: akpm@linux-foundation.org, "Huang, Ying" , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <30f4ac69-fb51-8414-fdaf-a1366a84bbd3@chinatelecom.cn> From: liuq In-Reply-To: <30f4ac69-fb51-8414-fdaf-a1366a84bbd3@chinatelecom.cn> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: E7A0716001A X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: o5zqwuey851qe77q64ux5fu1ngncfj97 X-HE-Tag: 1687335448-573023 X-HE-Meta: U2FsdGVkX1/LJW8Z1fPoObbNnwn5kCQGeF7i0DFB/Hhp4hAuz5/gCbxFq7R/KjMprWKx8fduWwQStsZwrVaEP1seKMNAAENM9HRJME0bQropLuzxPQX7ltec0IJJUziF/JrRisI4DH9aPXF/X6K3hOjojWxfJkr4F1RWh5+w5U4cIagofmuRD9hMXPWhuS5aneuLosG+lKmLPw12kZVBFAMaFO624F3mzXmirir2Yl4zA7iqGnTcTF50ej+5AHBYVegxamHq8i9/Kdg1dTjnCzSljmAJ+N/2XpjLkH9uRwJsj4eKyU7vU34x4us0PgWAxKpzgQ8SMx+Oqk3mzSS4vdAD+rLSgYlN3aG8UPXg5dUyuglDyFJ88XJIGuRxJzAjtS5lw4uqIDdqeS12kfckIFYlpJcdfF0iorioTaOgHHSMdIMJb+v/3oDNRXNwQ3Z2s3w+XXYF+r5xUekR6nlT1CHoO14mqIT1Je7lXzUfmeJ7QFaMddy/MCqHtHWZIEnNP1wCoPoUBk1ukKnTy6QvJrv32z/OHjjZI8Kq1sWOgou8tulEH43PCBiVNZa2rUZBX3/Z4B+jv2FVIUgX4Y6PvnVumI1UNXHKEx6VquB88b0qLddTaX3GP+dZ1uRWfJQgaTbU2VozeYZx3fIYEAH1sdK1Fff82Q0Qf4Asy3VO9uf2gmOxMVXpkOpoIMAVVd4/ij4Jn7ogmbMUEsEc2XFl7SnqIu1vAdedVIiTruPVGJ1mMS+WE1udNLBAaty1KYwcnLWmn3+wY/XxfRy+C+snYAQf8VAVSGiQR4Jf6a4N4IPLFEwgjbvOuHJOWf44UfF3fq5MbUq41gLnOWkqHyYP828dk9u2RZIakDztVzYAkkBrDpSwWFqPl44sSnVIfBdG8qRKHSUUEGDFRqwI5qS5iTSLJrWvHHhoGsoHu3y/5uAIhbA8PJORtFvMWSBpR/El3hs9su5+HAT576mfvFR sr5lK9Xl 4PzXVrFftLMI9JqHwrXuHSvRhVqEihFIKPBx2MAOY1y+ZCz3XzfVFXg8OxL6jTVHC0ehR/3BPP1hGYoYWKncNkThH1B5BEbbx5Uj+HqUVutJsja55h5F05M2fZUKgnFmnqFiSgvyum4AJWAh45TfBinNZvp6eEdXIaWO6 X-Bogosity: Ham, tests=bogofilter, spamicity=0.039445, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 在 2023/6/21 16:09, liuq 写道: > Hi, Liuq, > > Thanks for updated patch. > > liuq writes: > > > 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 moveable > > zone pages, so just like ZONE_HIGHMEM, cap pages_min to a small > > value in __setup_per_zone_wmarks. > > Please list the test result of your patch.  That is, WMARK_MIN before > and after your patch in a system with large ZONE_MOVABLE. > Hi Huang, Ying Thank you very much for your review and suggestions. I will send another version later. Best Regards, liuq > > Signed-off-by: liuq > > --- > >  mm/page_alloc.c | 4 ++-- > >  1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > index 47421bedc12b..608384712a89 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -6364,7 +6364,7 @@ static void __setup_per_zone_wmarks(void) > > > >          /* Calculate total number of !ZONE_HIGHMEM 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,7 +6374,7 @@ 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 >                                 ~~~~~~~ > > Change the comments above too? > > Best Regards, > Huang, Ying >