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 06C12C48BF6 for ; Mon, 4 Mar 2024 02:01:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7494C6B009D; Sun, 3 Mar 2024 21:01:20 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6D2526B009E; Sun, 3 Mar 2024 21:01:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 54C1E6B009F; Sun, 3 Mar 2024 21:01:20 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3F7026B009D for ; Sun, 3 Mar 2024 21:01:20 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id F18891C06A5 for ; Mon, 4 Mar 2024 02:01:19 +0000 (UTC) X-FDA: 81857704278.08.4B7A33F Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.18]) by imf28.hostedemail.com (Postfix) with ESMTP id C5772C0018 for ; Mon, 4 Mar 2024 02:01:17 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=j53y+inJ; spf=pass (imf28.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.18 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709517678; 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=5sMwyZCTkq0Ag8ON8cbUH28wvbjRo/bD1HM1F2osB2A=; b=Eu18pkKvX71Os5aMUvLBWbtvm4KWZZfk2iqqnDr3Es86rNG+mGkgpO9WUyFuvsRF8IA/Lf l6A//lePl0ozKqrrwy3djHWMVDfq5Q/zohqDxhqvEowNuWwQlITugG3zR/czOOLVyPtArF 0QNEyHRVYqH3BIrHJJtel4b1B6MWa0o= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709517678; a=rsa-sha256; cv=none; b=T6fxUurEYbZQLqHPfO+TsCN4WHORh3RjdapWCq1ZkzFlpVPCSSRRh22f0TP7/o9GXNtTA4 uyDyrHM/g47oDA22QqxAMvnJ5B6CBYmBBg56/IyEFbRLo5AGAG+5lZouGboTQuqVzlfnmV KRXBotajrMDkMOiUsJFjy/JSbRW2fOU= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=j53y+inJ; spf=pass (imf28.hostedemail.com: domain of ying.huang@intel.com designates 198.175.65.18 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1709517678; x=1741053678; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=TcICuy1so3NMfbwScETib/3oKVqxZpgBFgsX3pucsr0=; b=j53y+inJk0OQcCpzt8RNMIMc0N4ymjx0fTayM/siA7Phwr7cZobPiqq5 jBe452s78ZXIAey9+eq8eD6R1pm3c4Z59GdSDmN2KD0rs5ad+SUVJF9PY 07Vxzqoi2Bzm+kR8qLB05joQ/jj/V+xTSbsSoqLdTKBuok/ySbFP9VP+j MAotdmsfLzpnGfr0gRjGj7GPwe8b9cvuUT0BgzLuKO5H0NTsKRfDiPxMD fsAhRHTJJXJB7WPkGmIfhrqHFVoi+4gVYydc6oick7kTCPuQ3je3bUpRJ NN24MopCCrs2EQZt1LPM6fPWOsThPpcP+JfupqlL4WmT2u3AQyNt1cOm7 Q==; X-IronPort-AV: E=McAfee;i="6600,9927,11002"; a="4117586" X-IronPort-AV: E=Sophos;i="6.06,203,1705392000"; d="scan'208";a="4117586" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa110.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2024 18:01:16 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.06,203,1705392000"; d="scan'208";a="8774357" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmviesa010-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 03 Mar 2024 18:01:10 -0800 From: "Huang, Ying" To: Aneesh Kumar K.V Cc: Donet Tom , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Dave Hansen , Mel Gorman , Ben Widawsky , Feng Tang , Michal Hocko , Andrea Arcangeli , Peter Zijlstra , Ingo Molnar , Rik van Riel , Johannes Weiner , Matthew Wilcox , Mike Kravetz , Vlastimil Babka , Dan Williams , Hugh Dickins , Kefeng Wang , Suren Baghdasaryan Subject: Re: [PATCH 3/3] mm/numa_balancing:Allow migrate on protnone reference with MPOL_PREFERRED_MANY policy In-Reply-To: <878r2zlu1i.fsf@kernel.org> (Aneesh Kumar K. V.'s message of "Sun, 03 Mar 2024 11:46:09 +0530") References: <9c3f7b743477560d1c5b12b8c111a584a2cc92ee.1708097962.git.donettom@linux.ibm.com> <8d7737208bd24e754dc7a538a3f7f02de84f1f72.1708097962.git.donettom@linux.ibm.com> <877cizppsa.fsf@yhuang6-desk2.ccr.corp.intel.com> <87sf1nzi3s.fsf@kernel.org> <87ttm3o9db.fsf@yhuang6-desk2.ccr.corp.intel.com> <878r2zlu1i.fsf@kernel.org> Date: Mon, 04 Mar 2024 09:59:16 +0800 Message-ID: <87o7bubvuz.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Stat-Signature: o3bftxmgxz83zmfe46z5n19rk6bt3x3z X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: C5772C0018 X-Rspam-User: X-HE-Tag: 1709517677-46764 X-HE-Meta: U2FsdGVkX18xWakP6YJG3132ADFJuIXggK/XdroXkxCmquw4QW8VOBQj0/c//y0itfF0tr+JHT5vivUFwYEC4mUmgsmyRSKfp2Ptx9mN/AsU9uZizUrgY2qsBpL8wiM18rEoNne3qZwb9D6u+UKtBaZJqPYIsjb53uPzRaMMmf/AkeyuvuGouaTRHYLtRdkj2LNLw2/KLdq40P3AAVcxeE4UbFOcBss0QPYKZkVby6/mPP+5E5v+aCAbEUYgNoKeCPTlgjQxq/Nx83onTz3Yip0JdunmwaZneCwvpsv8RT8URGfWaKj+XsO3TAImQQvqICtXbw1fg64UUghFilUztVXnpoK39E+r1wojbgiQKONfurBGisfo6uUxo9ybgUeLPsBXpsvaeGHAdTC6Y3hoYH7AFT3q1R7utGtE5NLqbwxlBB7KVtT5MKGShfsE+fZagTgl7TLDp+4sncsdZcNq27OZHck8+wnzMSTn1J6LY+FP5wPRBMpFzMOVDK66X5pN9tF8uxP2p6MRLOJpQ70wYmGaveNqGSNHl6FE3kyynrSM4vUd5fKAvsAl56y1XdkQ4oUcYcY2w1P8BeKQMDMNXlJrFvcbRkquoW0PH4yeJWmhkJ9ZhMvHO2a4NIBmOrEGW0gQI2mqGtlGE0CZE/W1w5iiNHM6+z5sw0937aReKU++jWq+HALJquPZTMlXXxi2BePVNiIUqtIa4Mt3tEluB3MYE2zKexw9VlC9PA1vIwrXsfIo7mJhYCf7ZzLbccwZ4gcSMNELmBrht+aYf9XkgDagEd2XSsU0n1b+CcyBPYJaEDlOIihp8Aigez01fUsNoyku4Nqy0/IaierVHz4P6G/eLkRF8GqVt8WVw88cnfmo7zS84DJcc5xLoFASKxfVfoLx66a6Jmk= 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: List-Subscribe: List-Unsubscribe: Aneesh Kumar K.V writes: > "Huang, Ying" writes: > >> Aneesh Kumar K.V writes: >> >>> "Huang, Ying" writes: >>> >>>> Donet Tom writes: >>>> >>>>> commit bda420b98505 ("numa balancing: migrate on fault among multiple bound >>>>> nodes") added support for migrate on protnone reference with MPOL_BIND >>>>> memory policy. This allowed numa fault migration when the executing node >>>>> is part of the policy mask for MPOL_BIND. This patch extends migration >>>>> support to MPOL_PREFERRED_MANY policy. >>>>> >>>>> Currently, we cannot specify MPOL_PREFERRED_MANY with the mempolicy flag >>>>> MPOL_F_NUMA_BALANCING. This causes issues when we want to use >>>>> NUMA_BALANCING_MEMORY_TIERING. To effectively use the slow memory tier, >>>>> the kernel should not allocate pages from the slower memory tier via >>>>> allocation control zonelist fallback. Instead, we should move cold pages >>>>> from the faster memory node via memory demotion. For a page allocation, >>>>> kswapd is only woken up after we try to allocate pages from all nodes in >>>>> the allocation zone list. This implies that, without using memory >>>>> policies, we will end up allocating hot pages in the slower memory tier. >>>>> >>>>> MPOL_PREFERRED_MANY was added by commit b27abaccf8e8 ("mm/mempolicy: add >>>>> MPOL_PREFERRED_MANY for multiple preferred nodes") to allow better >>>>> allocation control when we have memory tiers in the system. With >>>>> MPOL_PREFERRED_MANY, the user can use a policy node mask consisting only >>>>> of faster memory nodes. When we fail to allocate pages from the faster >>>>> memory node, kswapd would be woken up, allowing demotion of cold pages >>>>> to slower memory nodes. >>>>> >>>>> With the current kernel, such usage of memory policies implies we can't >>>>> do page promotion from a slower memory tier to a faster memory tier >>>>> using numa fault. This patch fixes this issue. >>>>> >>>>> For MPOL_PREFERRED_MANY, if the executing node is in the policy node >>>>> mask, we allow numa migration to the executing nodes. If the executing >>>>> node is not in the policy node mask but the folio is already allocated >>>>> based on policy preference (the folio node is in the policy node mask), >>>>> we don't allow numa migration. If both the executing node and folio node >>>>> are outside the policy node mask, we allow numa migration to the >>>>> executing nodes. >>>>> >>>>> Signed-off-by: Aneesh Kumar K.V (IBM) >>>>> Signed-off-by: Donet Tom >>>>> --- >>>>> mm/mempolicy.c | 28 ++++++++++++++++++++++++++-- >>>>> 1 file changed, 26 insertions(+), 2 deletions(-) >>>>> >>>>> diff --git a/mm/mempolicy.c b/mm/mempolicy.c >>>>> index 73d698e21dae..8c4c92b10371 100644 >>>>> --- a/mm/mempolicy.c >>>>> +++ b/mm/mempolicy.c >>>>> @@ -1458,9 +1458,10 @@ static inline int sanitize_mpol_flags(int *mode, unsigned short *flags) >>>>> if ((*flags & MPOL_F_STATIC_NODES) && (*flags & MPOL_F_RELATIVE_NODES)) >>>>> return -EINVAL; >>>>> if (*flags & MPOL_F_NUMA_BALANCING) { >>>>> - if (*mode != MPOL_BIND) >>>>> + if (*mode == MPOL_BIND || *mode == MPOL_PREFERRED_MANY) >>>>> + *flags |= (MPOL_F_MOF | MPOL_F_MORON); >>>>> + else >>>>> return -EINVAL; >>>>> - *flags |= (MPOL_F_MOF | MPOL_F_MORON); >>>>> } >>>>> return 0; >>>>> } >>>>> @@ -2463,6 +2464,23 @@ static void sp_free(struct sp_node *n) >>>>> kmem_cache_free(sn_cache, n); >>>>> } >>>>> >>>>> +static inline bool mpol_preferred_should_numa_migrate(int exec_node, int folio_node, >>>>> + struct mempolicy *pol) >>>>> +{ >>>>> + /* if the executing node is in the policy node mask, migrate */ >>>>> + if (node_isset(exec_node, pol->nodes)) >>>>> + return true; >>>>> + >>>>> + /* If the folio node is in policy node mask, don't migrate */ >>>>> + if (node_isset(folio_node, pol->nodes)) >>>>> + return false; >>>>> + /* >>>>> + * both the folio node and executing node are outside the policy nodemask, >>>>> + * migrate as normal numa fault migration. >>>>> + */ >>>>> + return true; >>>> >>>> Why? This may cause some unexpected result. For example, pages may be >>>> distributed among multiple sockets unexpectedly. So, I prefer the more >>>> conservative policy, that is, only migrate if this node is in >>>> pol->nodes. >>>> >>> >>> This will only have an impact if the user specifies >>> MPOL_F_NUMA_BALANCING. This means that the user is explicitly requesting >>> for frequently accessed memory pages to be migrated. Memory policy >>> MPOL_PREFERRED_MANY is able to allocate pages from nodes outside of >>> policy->nodes. For the specific use case that I am interested in, it >>> should be okay to restrict it to policy->nodes. However, I am wondering >>> if this is too restrictive given the definition of MPOL_PREFERRED_MANY. >> >> IMHO, we can start with some consecutive way and expand it if it's >> proved necessary. >> > > Is this good? > > 1 file changed, 14 insertions(+), 34 deletions(-) > mm/mempolicy.c | 48 ++++++++++++++---------------------------------- > > modified mm/mempolicy.c > @@ -2464,23 +2464,6 @@ static void sp_free(struct sp_node *n) > kmem_cache_free(sn_cache, n); > } > > -static inline bool mpol_preferred_should_numa_migrate(int exec_node, int folio_node, > - struct mempolicy *pol) > -{ > - /* if the executing node is in the policy node mask, migrate */ > - if (node_isset(exec_node, pol->nodes)) > - return true; > - > - /* If the folio node is in policy node mask, don't migrate */ > - if (node_isset(folio_node, pol->nodes)) > - return false; > - /* > - * both the folio node and executing node are outside the policy nodemask, > - * migrate as normal numa fault migration. > - */ > - return true; > -} > - > /** > * mpol_misplaced - check whether current folio node is valid in policy > * > @@ -2533,29 +2516,26 @@ int mpol_misplaced(struct folio *folio, struct vm_fault *vmf, > break; > > case MPOL_BIND: > - /* Optimize placement among multiple nodes via NUMA balancing */ > + case MPOL_PREFERRED_MANY: > + /* > + * Even though MPOL_PREFERRED_MANY can allocate pages outside > + * policy nodemask we don't allow numa migration to nodes > + * outside policy nodemask for now. This is done so that if we > + * want demotion to slow memory to happen, before allocating > + * from some DRAM node say 'x', we will end up using a > + * MPOL_PREFERRED_MANY mask excluding node 'x'. In such scenario > + * we should not promote to node 'x' from slow memory node. > + */ > if (pol->flags & MPOL_F_MORON) { > + /* > + * Optimize placement among multiple nodes > + * via NUMA balancing > + */ > if (node_isset(thisnid, pol->nodes)) > break; > goto out; > } > > - if (node_isset(curnid, pol->nodes)) > - goto out; > - z = first_zones_zonelist( > - node_zonelist(thisnid, GFP_HIGHUSER), > - gfp_zone(GFP_HIGHUSER), > - &pol->nodes); > - polnid = zone_to_nid(z->zone); > - break; IMO, the above deletion should be put in another patch? -- Best Regards, Huang, Ying > - > - case MPOL_PREFERRED_MANY: > - if (pol->flags & MPOL_F_MORON) { > - if (!mpol_preferred_should_numa_migrate(thisnid, curnid, pol)) > - goto out; > - break; > - } > - > /* > * use current page if in policy nodemask, > * else select nearest allowed node, if any. > > [back] > .