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 0966CC4828F for ; Thu, 1 Feb 2024 15:27:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5724B6B0071; Thu, 1 Feb 2024 10:27:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5222C6B0075; Thu, 1 Feb 2024 10:27:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C3B46B0078; Thu, 1 Feb 2024 10:27:50 -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 2A0796B0071 for ; Thu, 1 Feb 2024 10:27:50 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 7A52AC0910 for ; Thu, 1 Feb 2024 15:27:49 +0000 (UTC) X-FDA: 81743615058.07.DA2E7C5 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf24.hostedemail.com (Postfix) with ESMTP id 2045918001B for ; Thu, 1 Feb 2024 15:27:46 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=CD6Xr1pc; dkim=pass header.d=suse.com header.s=susede1 header.b=CD6Xr1pc; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf24.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 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=1706801267; 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=tG3CpxDS02v6gYxnYwbFaNjzAhNUjXma24vFvRO3lrE=; b=xAIJbnxtJczh8tvqyd2Hv4HSvuZMvzIRsgODWgvRTtmV/9jnHKnFE2V/O7vrR2HojuxVWf xqWgzVwUd+HeCYfSi/WuGqsZL1QdcxU9iYIodaUlxwLRbA9iuEQ6KJH9vb8SAYm53aZsIh RVuxYZ7M6mSJYV0pyZ4NBTxiVy//vTM= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=CD6Xr1pc; dkim=pass header.d=suse.com header.s=susede1 header.b=CD6Xr1pc; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf24.hostedemail.com: domain of mhocko@suse.com designates 195.135.223.130 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706801267; a=rsa-sha256; cv=none; b=Anr5Wogwnj2ar1cFX0J2nDuFrLYf84v64PA67xCkjzxJ7Kz4gjbsUjGhauteU0wyfoK/hz 34lEKlx1iTtznovBURVzMUdx0w7vradE9FSHa+Z8VB8DPwNMR1DY74PJR1g7cV9ne4ccwl Hjng/IROrImsY4aQzzaFERRzgHKmkF0= 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-out1.suse.de (Postfix) with ESMTPS id 387E42207F; Thu, 1 Feb 2024 15:27:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1706801265; 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=tG3CpxDS02v6gYxnYwbFaNjzAhNUjXma24vFvRO3lrE=; b=CD6Xr1pcp1MOpdXP7WUqj63Qf9UNGqBnq1lU3nlxRU2oiJsOqc9pjRFzb2RVBWVeuIrLvW MwVuRtzHVs2chgGpu8cQStRn0+VRLRR5TLvqCVNtHxCQKFQbmPBkfwTvO+z9M31GF6bktc zJl/v7z9EmshwiNJVehzh12S4qsUfxE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1706801265; 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=tG3CpxDS02v6gYxnYwbFaNjzAhNUjXma24vFvRO3lrE=; b=CD6Xr1pcp1MOpdXP7WUqj63Qf9UNGqBnq1lU3nlxRU2oiJsOqc9pjRFzb2RVBWVeuIrLvW MwVuRtzHVs2chgGpu8cQStRn0+VRLRR5TLvqCVNtHxCQKFQbmPBkfwTvO+z9M31GF6bktc zJl/v7z9EmshwiNJVehzh12S4qsUfxE= 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 14077139AB; Thu, 1 Feb 2024 15:27:45 +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 droPA3G4u2V2eQAAD6G6ig (envelope-from ); Thu, 01 Feb 2024 15:27:45 +0000 Date: Thu, 1 Feb 2024 16:27:44 +0100 From: Michal Hocko To: Baolin Wang Cc: akpm@linux-foundation.org, muchun.song@linux.dev, osalvador@suse.de, david@redhat.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] mm: hugetlb: remove __GFP_THISNODE flag when dissolving the old hugetlb Message-ID: References: <6f26ce22d2fcd523418a085f2c588fe0776d46e7.1706794035.git.baolin.wang@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6f26ce22d2fcd523418a085f2c588fe0776d46e7.1706794035.git.baolin.wang@linux.alibaba.com> X-Rspamd-Queue-Id: 2045918001B X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: co86swxon7jbibiq8ezqyw4hjcq8rqoa X-HE-Tag: 1706801266-857454 X-HE-Meta: U2FsdGVkX1+CjC/u8tFHRFjkvRsD4YL1T9JnaAmlJWnmDtN1lBO2l0nYrk15GI5HR/gH1rxyBHqouALnsc3DeQVwRqHFrNOI4S4/CJWTVq1NMsyibZkP+bxpQf9aCu/IbBeC3qrwCLzBF3IbfLIEu7F/Q22797bnkIZ6fy0HjgnUAX+rj6r/MBIBvWzdiMoyxC97EAFWTFxqePUommO67Yg4z4554EsKDDIKiia81dBw86Zv4WojWq3BKOEeJ1j/DxsXvOr5OE4GG0A3YfV3ba4o0Ti5UCNaxQjEYpCaaHmhdCDYba6J8ReofkgrFpYjYzfJUYFhIqP3QGPFp6j2wLDIVnkRDtTNvzCfW4Tmo/YBw2nbjOtzIvS8L2w2O+YQZ6wUYC4VlkCcBF8s/9XdCfQCIh58+Jk/dHRoa2vdd2CurqeLrsTpVUTFqtK5j1xx+ZpoEgSPIGDBFoEltizigy7+b44q19I2fDnloRSq8Bly/jw3H5o9BGBh46B0jX1i8kM9ImN8+sYKBRmYO27n+g2ofthPaIfwZ7/d6Hqozj8soV4fYhVi1qaaG1+mAjjxgU9D8YBImsl2fvWIN+GiDZIhgE5wY6OqD1UZJg6GbOP4+Yij4WTm8h8ZpoowebwTTVWtCKzj6ACbwBiCMnvI3frqJx8JYiggPP3zH/EGu/SYA6q78iCAku047hUj2rTO6zf0xCrQ0F3UNQf1ujw+/DyIjgVlaTzcymm5vB03XpKn0vVfSV8Gz2e9axB/pPOSNp//hyu/xEVyzees4LpyJ5nA1WVpr7aWXDIVzGDP/C0kvWBBiEW+zYBza3NvuReBPuObg2Qg0ohdIBitgKfZt2+PiTIxUxDUwDP7pD0BAohF3HV83yi1fPxZABBK+SYt9n39QedV9DEyt0rAfkj3RiT3otp0EG/z+oCWelTgacMIHGa8bupoNIgw8X21BCLLZ7hNll+7cI8pojaSvuV am+44uoP kYdlwKnwuKmBh6pp/XcqLtOOyBvp6J+Wh7n6C4Hj5sjndvUGLutqvOsCOLS84a+3NHXQ/psXZDJrsy5Kos11Q7Q81NSbFCSnIbK54HG1MipLbhTMnqaflcked4wGaje6r2xP4Mn/l+GIeK6LbxBFplXJ+pumeqHEq7JkoT5KPKuKwFV3ghVKK5qbcXzODzuM4OI+Ezm04xpPeHkZ+q3U7rd9WpF2EUWVfn8+8C3Hp6ZU+peE6rjtV7Td9leBEqi64J36x 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 Thu 01-02-24 21:31:13, Baolin Wang wrote: > 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. I do agree that the inconsistency is not really good but I am not sure dropping __GFP_THISNODE is the right way forward. Breaking pre-allocated per-node pools might result in unexpected failures when node bound workloads doesn't get what is asssumed available. Keep in mind that our user APIs allow to pre-allocate per-node pools separately. The in-use hugetlb is a very similar case. While having a temporarily misplaced page doesn't really look terrible once that hugetlb page is released back into the pool we are back to the case above. Either we make sure that the node affinity is restored later on or it shouldn't be migrated to a different node at all. -- Michal Hocko SUSE Labs