From patchwork Thu Feb 1 13:31:13 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Baolin Wang X-Patchwork-Id: 13541080 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 F14D9C4828D for ; Thu, 1 Feb 2024 13:31:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 847626B0082; Thu, 1 Feb 2024 08:31:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F71D6B0085; Thu, 1 Feb 2024 08:31:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 70C9B6B0087; Thu, 1 Feb 2024 08:31:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 5EB5C6B0082 for ; Thu, 1 Feb 2024 08:31:31 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1E36F80DF7 for ; Thu, 1 Feb 2024 13:31:31 +0000 (UTC) X-FDA: 81743321982.18.03B9670 Received: from out30-101.freemail.mail.aliyun.com (out30-101.freemail.mail.aliyun.com [115.124.30.101]) by imf29.hostedemail.com (Postfix) with ESMTP id 7FC09120007 for ; Thu, 1 Feb 2024 13:31:27 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=FZsT71JX; spf=pass (imf29.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.101 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706794289; a=rsa-sha256; cv=none; b=jON/Jdf0UCUy958ztFQJegHK9SslHdiFR1ZkZ7Fmsy4FNoFdlRUDEDd/u+SacUA2WGU+c0 YzC/QRM7lkdzOEIEVpES9gJdFxx1mMqlRxiokyGgNN8BnMRv0B3TIlh47onWCjXYj/qrB4 398LFkRDy5+mq0Dpsc4jONTB9lPP/tc= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=FZsT71JX; spf=pass (imf29.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.101 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com; dmarc=pass (policy=none) header.from=linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706794289; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=YTeBhqdSU74IlpwBPcbqYdhQu9vEwdBX/KgZ9rQ8d00=; b=tcArmpV1deZ+9RGkb6nGID+qFe5XSRTQAdguL3xfWdD52/AYZeDvYT0ZTz+y1Bhj8DaT+A ggdLw0PizvjAbHO0aTZ3RtC2nO8JsMfq3nCsFISCiqZuOK7jxfVAAfsVUny+Q7Qd0BtZYO dejKy9xJQWsDXi/o7X9CXiJZDm3A4VA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1706794283; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=YTeBhqdSU74IlpwBPcbqYdhQu9vEwdBX/KgZ9rQ8d00=; b=FZsT71JXyzzlLKHLjRvI1ZyGFRKQgkktmPMuvm/iIBJEtZoVjFqBCmjlLDC6Sv2jbt1IVhOY+HHaUy7ZT05RzW2QQmXr2vh112hhAoWg2oIZ52o5VuzBF21WLta2sGWtlSq0nCDf0IusxgZ+aQl6sjsspPdqd0fs0pCN+GTljCk= X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R161e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=ay29a033018046059;MF=baolin.wang@linux.alibaba.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---0W.tpA.q_1706794281; Received: from localhost(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0W.tpA.q_1706794281) by smtp.aliyun-inc.com; Thu, 01 Feb 2024 21:31:22 +0800 From: Baolin Wang To: akpm@linux-foundation.org, muchun.song@linux.dev Cc: osalvador@suse.de, david@redhat.com, mhocko@kernel.org, baolin.wang@linux.alibaba.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [RFC PATCH] mm: hugetlb: remove __GFP_THISNODE flag when dissolving the old hugetlb Date: Thu, 1 Feb 2024 21:31:13 +0800 Message-Id: <6f26ce22d2fcd523418a085f2c588fe0776d46e7.1706794035.git.baolin.wang@linux.alibaba.com> X-Mailer: git-send-email 2.39.3 MIME-Version: 1.0 X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 7FC09120007 X-Stat-Signature: 8tw99drte9m45edxy9irgekd3aefrard X-Rspam-User: X-HE-Tag: 1706794287-874184 X-HE-Meta: U2FsdGVkX19D6Zm+daI9fWI4+xENWBKSykK8D2sKjNh/HIiESv2yoT+nC+9AyBYBg6u6h06FiH0iA/aDrAtP+WiIWDkz+1kAdtpf1cooq6/nra4zURU+57sJB4ja4oHBmshNSy0oebxrjdhGtIiSMd4xuxj9G8dHNRqXdgTaJ+Wf1L9VZ9ZTyRHtP7U9M1Gx5djo5K6IqSdTzdmEQ2iekvTT4S6FpS5WBRFNiKwffHJYxSrwncY0oeYZYltEFqCxGKa0n/8qfE5J1FsA6tl7CkdfhuFEHC4Gq9vUCM9Vipu5owIULsk1ybCKPjb0Z3r7OMnxFncTzDoSwJrmNMlikv5bhLZje+p9gc1Ml4J48Z9tviu0TmvBm03aGKmirXhAXwvRd7LkwRGIt+vKQ/XHbprg+QPKzfK8PFasd3uJ87GlUd80Hocdbx/gsM1eTLLVRSh3Iw8b5B7rB4S9QSo3xoENDXuvd228fsErpUxK6G3TSxb/u0T3W/RAorC7qVuMkbzaTLUMwyqoVwUu+GdO3ZPb8bSMUUT9weH2DnXt3qxBGjbPtZjRBTN48cwxX08dE4XhsIaOqCby0nqeoQahID2MrvVQw/2aL6PXV2yexUyoPY/9gag+VQG4m+N/hhGRD8J0EtBEkFo/RSPrmkD094XaEtj/yrq/YCud7QdX7zihhUwA9l1gFFxQzeH/fIqSGs0HvapzdMT1zB242JdV7mqvyBV9swV6cEzoJIgvOZ6kKK8aJs4jf1uBTivbrqgAhQ/HL3Ao1NjAybbQgS56+CUWbgJId+dJWhQEF1M2SvV91Q8HQY0AHy9QNlEgRLeiSPnAlrKAmw2L5HYjlMjyy63GKkInL8V+xhEIcOvPJ7jKfne+SilWf7QMmaQBdiiFzvFK0nSD7rYDYMjt9XkRAZB48+5HbgMrgtsvcoALkIX8bOzwUHOwv1v8rdMD8CzNcehTJ5KcmYP/1mAw9FT W1ZH3+JX HifC+9evnmm07yG/6H4fvbBcJaHjd5pGRhr6gHB6K7MscUsF88dXsqXYn/SXGbV+0Z28CyTanDeSp0t7sJLmMCY72ftXuhCRHOose88L59RqF0XUqRSwyKWBnEloOupW2CNRbXcQ4UGTVBDlXjChtoUy+7AtdLG1pLTniqnm+71hdYCYCDWN6hqO/82Bu7+2YDlirE9w9ky1ckR3OVvqsFFAbLreSgDrYLj4E/VqzxtUzaoli7pBRC9CnhN96GaA8XOavm4U1ZjrMuhY= 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: Since commit 369fa227c219 ("mm: make alloc_contig_range handle free hugetlb pages"), the alloc_contig_range() can handle free hugetlb pages by allocating a new fresh hugepage, and replacing the old one in the free hugepage pool. However, our customers can still see the failure of alloc_contig_range() when seeing a free hugetlb page. The reason is that, there are few memory on the old hugetlb page's node, and it can not allocate a fresh hugetlb page on the old hugetlb page's node in isolate_or_dissolve_huge_page() with setting __GFP_THISNODE flag. This makes sense to some degree. Later, the commit ae37c7ff79f1 (" mm: make alloc_contig_range handle in-use hugetlb pages") handles the in-use hugetlb pages by isolating it and doing migration in __alloc_contig_migrate_range(), but it can allow fallbacking to other numa node when allocating a new hugetlb in alloc_migration_target(). This introduces inconsistency to handling free and in-use hugetlb. Considering the CMA allocation and memory hotplug relying on the alloc_contig_range() are important in some scenarios, as well as keeping the consistent hugetlb handling, we should remove the __GFP_THISNODE flag in isolate_or_dissolve_huge_page() to allow fallbacking to other numa node, which can solve the failure of alloc_contig_range() in our case. Signed-off-by: Baolin Wang --- mm/hugetlb.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 9d996fe4ecd9..9c832709728e 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -3029,7 +3029,7 @@ void restore_reserve_on_error(struct hstate *h, struct vm_area_struct *vma, static int alloc_and_dissolve_hugetlb_folio(struct hstate *h, struct folio *old_folio, struct list_head *list) { - gfp_t gfp_mask = htlb_alloc_mask(h) | __GFP_THISNODE; + gfp_t gfp_mask = htlb_alloc_mask(h); int nid = folio_nid(old_folio); struct folio *new_folio; int ret = 0; @@ -3088,7 +3088,7 @@ static int alloc_and_dissolve_hugetlb_folio(struct hstate *h, * Ref count on new_folio is already zero as it was dropped * earlier. It can be directly added to the pool free list. */ - __prep_account_new_huge_page(h, nid); + __prep_account_new_huge_page(h, folio_nid(new_folio)); enqueue_hugetlb_folio(h, new_folio); /*