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 A94EEEB64DD for ; Sun, 25 Jun 2023 01:43:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E3E088D0002; Sat, 24 Jun 2023 21:43:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DEDEA8D0001; Sat, 24 Jun 2023 21:43:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CDCED8D0002; Sat, 24 Jun 2023 21:43:41 -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 BF09B8D0001 for ; Sat, 24 Jun 2023 21:43:41 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8750B404F4 for ; Sun, 25 Jun 2023 01:43:41 +0000 (UTC) X-FDA: 80939573442.27.40A6484 Received: from mga06.intel.com (mga06b.intel.com [134.134.136.31]) by imf16.hostedemail.com (Postfix) with ESMTP id 7D3B3180014 for ; Sun, 25 Jun 2023 01:43:38 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=D5zr6LHE; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf16.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.31 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1687657419; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Okqcx9vAehH68SGZGp2Hzua8Z2lgK/PkFOuXG13MENs=; b=blU4CnHNEQJf7nrJta6q+jph4TGWlcwYv8btG3vquuohKlc2R0Gq4uL/iAlxESHiCjhUNQ H86l5cQFvj4/FlcY/lV0jn3MJg26U69yX2syODlqPBCR2L5oMqtNAvAgZTQZe3PAJ+XI1R yYKGPVwe80WjE7Z6cjQOO17yij9eN80= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=D5zr6LHE; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf16.hostedemail.com: domain of ying.huang@intel.com designates 134.134.136.31 as permitted sender) smtp.mailfrom=ying.huang@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1687657419; a=rsa-sha256; cv=none; b=ybat7NCj1/v3ITS2dllCtsPMXQJbh2jMoRQ9Iq5c7LmUoB0x3IWsIz977OhzjtqcKGMfJX ESKF4n0cdStcj6s3arf6V2MFifPgvBgFTvo1obncQ1wUmfq3wHzhSqXN/O0OCUrM0hkxfF jXkmevnUGdV+XRPKnLlwsP2RunsVTqc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1687657418; x=1719193418; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=B5nFWmooHRky6c7V7OQZwlVIr7FyW8jco6PLxS4Zwwk=; b=D5zr6LHE1W5UtNn3SPC/P9Ux/SKFr7Tbu+DX3a7qsZb4Adj203ojPD4V fkNvaDElFt8QoU9UaRxHMwpZmDpKR3CIwdizGsqMeuRiuhtKp58xs2HDC D0pJcEtkBdZp20Sbs0Ks/CR6YdQpSjHCRtcunDl8M7BSvAYXKxw1WK4fS l8kuASSADLqGH0HqkLcLk2BNqYiB6unJsQxaOxBGfuw1Hu1oRbC4QIoOU n5VS0XrjmJcm4sdOecyBxxLADfk0szkj5IiTlKnZgfTQsJDQBKRuJFEo+ sHgKFUZeyIywTL72HrC3xJLkjLSnV2TI8pePDCZ2pnSqX1p7RvykAn/VC g==; X-IronPort-AV: E=McAfee;i="6600,9927,10751"; a="424682015" X-IronPort-AV: E=Sophos;i="6.01,156,1684825200"; d="scan'208";a="424682015" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga104.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jun 2023 18:43:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10751"; a="839852478" X-IronPort-AV: E=Sophos;i="6.01,156,1684825200"; d="scan'208";a="839852478" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jun 2023 18:43:34 -0700 From: "Huang, Ying" To: Kefeng Wang Cc: liuq , , , , mawupeng 00564683 , Mel Gorman Subject: Re: [PATCH v3] mm/min_free_kbytes: modify min_free_kbytes calculation rules References: <20230621092048.5242-1-liuq131@chinatelecom.cn> <2fb1f6dd-afea-caf5-a94b-6915b21258a4@huawei.com> Date: Sun, 25 Jun 2023 09:40:20 +0800 In-Reply-To: <2fb1f6dd-afea-caf5-a94b-6915b21258a4@huawei.com> (Kefeng Wang's message of "Wed, 21 Jun 2023 18:00:25 +0800") Message-ID: <87pm5k720r.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 7D3B3180014 X-Stat-Signature: hnok55tmopw7z3mwhnw57s1badnkxiyk X-HE-Tag: 1687657418-86734 X-HE-Meta: U2FsdGVkX1/PbRYcI7oYbgZxPg2W/M7CPMaKc/62jZLLec8hrqxac37a9iOxj35tL9TGMk4IVJB9kBwCZzeYUnJG60DODgeuXxrkZxts+pjqc2QU/0fxnhClwo7mTYtNEbzucW+B5T6qxI934HFp0NVTLauagurDcGBu7PFVAD6NZf/f1QXk3KbWgYBn8cckm54RpGPmEHugLhC1Cu/Y7gbFrHk2FreVzkjFdkM4423a7oFgH1FcZ4Ti+5jPlYQgSWcUcokSVdWp78/RUU/r0cU09yAZwvNAsRR0y9pCqdvrO3d0alBKmR5X1bKsjw+a1YfoDsZwznCob6ib1Eu3EVtSmyCbsXYijs7NrOZmiaKWRaiw7gKdUyJfy4D6UQ1Z0nGJeltvFcNzlFcTpD3D9XJHOCIIIfb6WNSLSxYIB2TI4OWhd/J64TdOI3se0Ll3MFzKlQNJ4WhEtg3VCkIio4NklZRfyhG0nGzw8W67Gd8Ue40wZccwkffJVgwKKip9Jb1R4WZiFaWvsq2jwzMuNYzTrF6mC5xTaSEP8ru9WzDmiU6pRHVRx3ZmVbvpwZxfYagbOxnfRJiWPzL5m8ouB50vTlIffV59ZSQZOh+asWSBhoyrXMubzgJjU698Dx+LjLQ1b/vqAptpMr/AYhP9Lsfp9lBLATDaWj71kW9J4MaudWALamX0nT6jKbOOJCopSQolSfy/JUCgYWHF/TAyIyl+9j2oWYzyyZNnc1P+1bscasPeEQ9ScKQxF0vaha3maPEaCmFG4NogxfgjDqxeHp7B4H1osKe48WkVV9ptVDjH+AxRtikqbF91xFfCL8h7cwuXxWGlGj3rp3HNMpzsRwxJN0VJJjkjQmzVNsuNECwuFL9PHFT4dBVOFyYpAJrgVETYB2U1zfzKiHGKq8pP7ss3vsZyjlE5UmuegN2yh4J4smf/kMgsWCsYK0UZ6DaZ5pyR7ejOAhee2RLNM8d /RSt1qCy lovU5k2mBWvvrOpeglZ6CP9Ns2GAZeXHrP8fYmLd9e2d7NwcnGaiY96nUWQuFQSh9fHM4XusfqrEQHF+x2XVJoZNeZ8dN+lTdpvyU6gz7I435wJN47jvLRtMX6HjnnuiSdNDu8Dc8KUFb6T/bbFXzXEo8rVYhsPPbz+GVZJPU/awJYtIQixyo/+A/wtYQEYh2Rl20nBNboI9BhY4+N9zXofDWzBv7f4L4Srz2vDY/xKOJjfhU7FKr7VhkE150UY8oo05+cyb2ugIEqjnFcLxvA/w48A== 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, Kefeng, Kefeng Wang writes: > 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/ Thanks for your information! That's very useful. As Mel said, ZONE_MOVABLE or ZONE_HIGHMEM pages allocation will need low memory to be allocated too. But I don't understand why higher min watermark of ZONE_MOVABLE will help this. It's too small compared with the size of ZONE_MOVABLE in most cases. For example, on the system of the patch description, the original "large" min watermark of ZONE_MOVABLE is only (1434 * 4) = 5736 KB, which is too small compared with 12 GB total ZONE_MOVABLE size. That is, before reaching min or low watermark, we will allocate almost same number of ZONE_MOVABLE pages: ~12GB vs. ~(12GB - 5MB). Best Regards, Huang, Ying >> 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; >>