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 CAF75C48BF8 for ; Mon, 19 Feb 2024 12:07:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2332F6B0078; Mon, 19 Feb 2024 07:07:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1BC3F6B007B; Mon, 19 Feb 2024 07:07:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 05C0E6B007D; Mon, 19 Feb 2024 07:07:36 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id E41996B0078 for ; Mon, 19 Feb 2024 07:07:36 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 813421602CE for ; Mon, 19 Feb 2024 12:07:36 +0000 (UTC) X-FDA: 81808428912.06.6D12BE5 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf25.hostedemail.com (Postfix) with ESMTP id 45CB5A0003 for ; Mon, 19 Feb 2024 12:07:33 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=pgQnDRCt; dkim=pass header.d=suse.com header.s=susede1 header.b=pgQnDRCt; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf25.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.131 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708344454; 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=Z0a/KddcLKmhK2Pu1JkEfLqBM9Cv44V7yFOdZCyPJ9I=; b=EaBSJC3KdZLW9TeUN33d6NA0GEhnZDNbflXnhPJ/3dAvCeGsnAe3YMFv9L5eUvBRPAgXQP SA1Nmwsmnjk6Jy2OItnjLWILnAQADJi/5sfbVJXq3IH1717BtGtgEBM92SHC2XuEmlt2V/ pRkZXu7zETdDiYP5++Jh58GsKbzADBM= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=pgQnDRCt; dkim=pass header.d=suse.com header.s=susede1 header.b=pgQnDRCt; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf25.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.131 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708344454; a=rsa-sha256; cv=none; b=mJntPlx3G0ylv2COSLKfA6Se2kT90k9f+OCjO0WOlu5628iKQh9LTQuspefTIK3c0H1htt Kl73UQDogYwKR4NOdinqWGP/U4O2XE54dhObFbp8tN/WfldBLOUnGOKCRAoWiMuXTo7Nev /0julzpoi8C2LjD4F84HwA0h4OLC/3U= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 7B2D21FD08; Mon, 19 Feb 2024 12:07:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1708344452; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Z0a/KddcLKmhK2Pu1JkEfLqBM9Cv44V7yFOdZCyPJ9I=; b=pgQnDRCtmlh5EOcF3ZdBgkI/xnPrlEqIusjMT6GNppnwaC7BTcBLPyEZlHBJljZkFI/cJ8 0mz3kXR9tImVrJleTm126gLED/2mQ/5MVj4nzZOz6KTu0m1axAjpVETb8/mPHvIm/oqijX WbxhPHb5XnoxciPDIusG+2z+YFPj7Nk= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1708344452; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Z0a/KddcLKmhK2Pu1JkEfLqBM9Cv44V7yFOdZCyPJ9I=; b=pgQnDRCtmlh5EOcF3ZdBgkI/xnPrlEqIusjMT6GNppnwaC7BTcBLPyEZlHBJljZkFI/cJ8 0mz3kXR9tImVrJleTm126gLED/2mQ/5MVj4nzZOz6KTu0m1axAjpVETb8/mPHvIm/oqijX WbxhPHb5XnoxciPDIusG+2z+YFPj7Nk= Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 587BB139D0; Mon, 19 Feb 2024 12:07:32 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id uDGYEoRE02ViPQAAD6G6ig (envelope-from ); Mon, 19 Feb 2024 12:07:32 +0000 Date: Mon, 19 Feb 2024 13:07:31 +0100 From: Michal Hocko To: Donet Tom Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Aneesh Kumar , Huang Ying , Dave Hansen , Mel Gorman , Ben Widawsky , Feng Tang , 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 Message-ID: References: <9c3f7b743477560d1c5b12b8c111a584a2cc92ee.1708097962.git.donettom@linux.ibm.com> <8d7737208bd24e754dc7a538a3f7f02de84f1f72.1708097962.git.donettom@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8d7737208bd24e754dc7a538a3f7f02de84f1f72.1708097962.git.donettom@linux.ibm.com> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 45CB5A0003 X-Stat-Signature: zgwatk9bfsiw4jz96eejo1cr1ok7u9h7 X-Rspam-User: X-HE-Tag: 1708344453-569794 X-HE-Meta: U2FsdGVkX1+L1fyDnw+mLYOB/J6HPk3VTQal72k+15YzwWC8E9snJ2L0qoJOYpTL2TheXMwU266pL9y8UOW16LuUwshwI7FELydGzc3sSyq9F9/ysTWv+zm1k+qCd8Uj15jUfbxDf+nzFitI+/gkp5BKTc2Y67CQFVpEZK/mslqSWqZQLuzGqiih7xdvYm2ETnLfXGgVVQvZVZSBVV2hORjKcQZ9SuKr1mWQldjSS20kslVPtmhHuezaU1/Wzb8lFhpJd9jKgI6rPnq4/YuG0xd4KKD4MMbh6nzrNvdmVZ9oY60FjZVphEE4UwLT3XpO6k33i644eNNSVKg+/MWm3gYvS2kZhajugIw+QjA9cuWzoyjT65a/a6oAAr9gDo/qWvjQFef5ff9XFLJhfp75GkF34FLE/Bc7jXzIe0m3X5xYB7rE1/LHi27+yhT4N1uS6Cm4Pt1KmyVoHudasFzbdlhjLfEkiZEQSXTix2ikavsx5ryet7TEZJtYa5VlCnz7I/bNsHlf2Qi0vk1bVbSxyG2Kuxnog75SzQEdsubZCVBTfQ4FWraIZ/ynCkJ3I5LLRiY96w4nCV1L9Afkx/r7B4MbKGuAHKmKO6HOSU9idwZElY9gOYmda0nMLN+Nv1YSDxPYM+945fe2Zo3QES1i9NlE9gOP+ZatG8KwWqj1j5RhCR6vCAYw1eWxTh5AQRWKT3eZynHj7jqhQvdbwrJfFhsErGx39ScbEXBApMXsK0VywfATYIn9FMfHzmsk7oGaFjDLMtj4VHhvTDKSJww0+flrlCEaUhqkca0lQljEMlGxcbvYsSB3Drzq3hnAuq+W26bOT5M99Xc43d94WwEaXIXI3AAu8jz+t/oMBo3s3S+VSQoG8fFRND8FOg75/a/08WUHChSy9/kqscD+s1/0t0AMIZRqMO/cyvtNC8VbH+wITu2vwAI/9kjJPH1x9md9yNfjLJmJNisbYsOkrGd dmg5M9lO a5J22n+BpNXKHzaYOaXJJ6kTSBD03VDoHDELKFJQeH33gQfIR5Lhvl8r7LId+yb94MEgl8J8XUegXOhIcIIvjDOmhkmfsMmC3zzj2zEVWEhWGAbxKD/nYnn+U6UhsVqRLss+QNqBXc3f/q8Pv+EvR0JZBETZ3NIMqnZjHZM9klWHuKQuQVWwHCdh5X58a+k706VTfDxa1W4kCVVg2MekC+6oROB8RegYoslOgIoujkfFOEywNI1epQKZ3zrAWNhC0tOZm7ZTOM3nb+VSMXW0hqoPxjreNKcKCXll7AEhfwX+PmwqR3RNucTsvPb1NHL5P2Q8CxuD3lam1hybDnCxKNv1lw+qXDOSYzh+r 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: On Sat 17-02-24 01:31:35, Donet Tom wrote: > 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. The feature makes sense to me. How has this been tested? Do you have any numbers to present? > Signed-off-by: Aneesh Kumar K.V (IBM) > Signed-off-by: Donet Tom > --- > mm/mempolicy.c | 28 ++++++++++++++++++++++++++-- > 1 file changed, 26 insertions(+), 2 deletions(-) I haven't spotted anything obviously wrong in the patch itself but I admit this is not an area I am actively familiar with so I might be missing something. -- Michal Hocko SUSE Labs