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 6AA6EC48297 for ; Tue, 6 Feb 2024 13:20:00 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8ED016B006E; Tue, 6 Feb 2024 08:19:59 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 89D506B0071; Tue, 6 Feb 2024 08:19:59 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 765756B0072; Tue, 6 Feb 2024 08:19:59 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 636FF6B006E for ; Tue, 6 Feb 2024 08:19:59 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E8803C0A53 for ; Tue, 6 Feb 2024 13:19:58 +0000 (UTC) X-FDA: 81761436876.05.73DE205 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf22.hostedemail.com (Postfix) with ESMTP id 99894C0019 for ; Tue, 6 Feb 2024 13:19:56 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="KGjZfM/+"; dkim=pass header.d=suse.com header.s=susede1 header.b="KGjZfM/+"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf22.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=1707225597; 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=jIPgOyeIYL9r0eG/hKiBxs+y+4PiJBAJiwveUceKmG0=; b=JF9MxdTJH1c452uO550HKbhxYYL2pwAkQsTHwBMWyRb6zK7qpLK+7NyquQnSuIb2gRjo0q r5aBLwMMzzHOgutdUhoC2CqmM8IcdUNVSk6JfPuJ4l+tTugmHJXrubLBtZ68J2guJvWsTE yEeHAvCZ+3wpbunvFRWiGEqecuFk1Yo= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="KGjZfM/+"; dkim=pass header.d=suse.com header.s=susede1 header.b="KGjZfM/+"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf22.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=1707225597; a=rsa-sha256; cv=none; b=1L84Ue+sp7V5OMi1tivtDFcfvK/ddUzKygre4P0DruMBgr/Y/vvfQBeMwImtBUFgnh2VBw g7xyjIMbpD1hdZpNdaTuppptYVvb7E5Imhfz/o86UdY4NgHWnMDdK4j7HsXd7DW/Ugmjae jOM+dxwz1JUhcDYxz+1Eu+cGe9nf2oI= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [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 9C40F221A7; Tue, 6 Feb 2024 13:19:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1707225594; 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=jIPgOyeIYL9r0eG/hKiBxs+y+4PiJBAJiwveUceKmG0=; b=KGjZfM/+UVaYOKUcTJtRkPTY5oNZNLarIiuiZWWT5saOhUjV1cmktOm5HPdcZQuiFI5czv hhw5u9ErWm138FhM3SGJhIqLp3i9eUZpeGlk8dRlsFUpByLYoHOTNklZ5bJvjCScEPx6Az x+NPmovmRfx4yckHhBy+YApP6IeOq3g= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1707225594; 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=jIPgOyeIYL9r0eG/hKiBxs+y+4PiJBAJiwveUceKmG0=; b=KGjZfM/+UVaYOKUcTJtRkPTY5oNZNLarIiuiZWWT5saOhUjV1cmktOm5HPdcZQuiFI5czv hhw5u9ErWm138FhM3SGJhIqLp3i9eUZpeGlk8dRlsFUpByLYoHOTNklZ5bJvjCScEPx6Az x+NPmovmRfx4yckHhBy+YApP6IeOq3g= 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 94628132DD; Tue, 6 Feb 2024 13:19:54 +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 fio2JPoxwmVGOwAAD6G6ig (envelope-from ); Tue, 06 Feb 2024 13:19:54 +0000 Date: Tue, 6 Feb 2024 14:19:54 +0100 From: Michal Hocko To: Baolin Wang , muchun.song@linux.dev Cc: akpm@linux-foundation.org, 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: <3f31cd89-f349-4f9e-bc29-35f29f489633@linux.alibaba.com> <909cee7d-0201-4429-b85d-7d2662516e45@linux.alibaba.com> <2613b670-84f8-4f97-ab4e-0d480fc1a3f8@linux.alibaba.com> <67e0d81f-7125-455c-b02f-a9e675d55c6c@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <67e0d81f-7125-455c-b02f-a9e675d55c6c@linux.alibaba.com> X-Rspamd-Queue-Id: 99894C0019 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: dudw9uyyi4rj919ksac74i496i7obg7n X-HE-Tag: 1707225596-818287 X-HE-Meta: U2FsdGVkX18ty0SpVJAvECioV0mPGEp2TfnBhFD8Aw8sfM2PSEft5WrL74DYb83dRn+8KJWb/C4HjYPa6PSsY2Px53BjRSb/hokFJpM+D2d/qFJWOFB5lpOgnnoypyTBztewyqGkWchZ0y5VcNPDF2x/Gplq8jbWJfGzhzNacoWnwqeQebMuPHjyLOnGUamtzpgdsi3GiWv1YWNcJTIeqV2wUFGKVnASXYBhCk1VpVp7MWm8e1Z+KOgfiEqQgTRCaOLgq0tTfV6Vv/apneLj1sLeWz8H11x0JaNAW0quGthHlzL44EE+xl5Uxnl9FNq/h6ZSAzE+bR/eWmTNiKdyttguPYqNOdIHs9csiqRu3dediQFzxd5B+dzxJ2GTcKa2EiUBMvtAcF9MB/cW25b7voaDKd1Fta1HUvXl4Ty8jMZ6Re2YwXTP80ZlUqCooloTCg+Bm/GG/oxgvVDfoH6DSNkBlPQP8tj7olja0+YldLPEt1Xdy24dq+Anc3fqrJ1BwmcBo/Shd9OKtY9yXY/puDk4kNdv51yz4cgOe6h5LVq9WZfhHbYmOfdGMunu4xNNiswjJCiACuDLNF78U7H5LU4xKQpAWgr/qCKq8P73YVTKqjken2SpaqAlAWXZdN8KqRXJ3b9e8XFdTYzRJIrk6OD34jD/GqEuSTP8D9KrlBdTlGSSPa87dLG3HrRy2BaysxaAYGuBaRYBGOoaufQOQJViWSI7IXE9GGNmNYcvVIenx+UyHkA3j6vAeesPuJYbnoG6TuxmErhyTroua6Wchugq0PzawfQIwOP4A8zqh0AoditRTpQ/NBuhecE4e/udS2rna24g7iPLdH61Y6nuK+Opqf5dm7H8qqPuq2EdNWguiCqnYJnisT+NU84zKFvt3hisScl4ZOvrgAQ4ILiPNo9tSm57yiuDsN7QcnZ2FkxXF5h/UUcphBwYQ/7y7vHoFJox/Hn17Ypg5ddSQle qd1FAFpc IyVxw+CNV1mSbpnYOHs8i9lAldKCGCStUEeQoFJ/u6pHDo2DKWYCxfbcfRxOCbIEZyvsJMtUcDUnnm6LJ6ZVQM46YjIU4kX3jM1XUKL5K3bn/E2TtlERobi2pYWj0HuWe9UnHiWtfAyUqNnlVyB2saOhxTyDqs3r33P/yVe9dnKCKWis2f+jFtP5a2ubTUoRtzW+pO40pElrvM+u3Wh5nJuiDS8DlWIGX2KP9R1I1azW3bfKVevW2J1ff5/4ivk9TNduSYYDSp/UeKfWeiq6XLAdhVvff6DUC6uXC 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 Tue 06-02-24 16:18:22, Baolin Wang wrote: > > > On 2024/2/5 22:23, Michal Hocko wrote: > > On Mon 05-02-24 21:06:17, Baolin Wang wrote: > > [...] > > > > It is quite possible that traditional users (like large DBs) do not use > > > > CMA heavily so such a problem was not observed so far. That doesn't mean > > > > those problems do not really matter. > > > > > > CMA is just one case, as I mentioned before, other situations can also break > > > the per-node hugetlb pool now. > > > > Is there any other case than memory hotplug which is arguably different > > as it is a disruptive operation already. > > Yes, like I said before the longterm pinning, memory failure and the users > of alloc_contig_pages() may also break the per-node hugetlb pool. memory failure is similar to the memory hotplug in the sense that it is a disruptive operation and fallback to a different node might be the only option to handle it. On the other hand longterm pinning is similar to a_c_p and it should fail if it cannot be migrated within the node. It seems that hugetlb is quite behind with many other features and I am not really sure how to deal with that. What is your take Munchun Song? > > > Let's focus on the main point, why we should still keep inconsistency > > > behavior to handle free and in-use hugetlb for alloc_contig_range()? That's > > > really confused. > > > > yes, this should behave consistently. And the least surprising way to > > handle that from the user configuration POV is to not move outside of > > the original NUMA node. > > So you mean we should also add __GFP_THISNODE flag in > alloc_migration_target() when allocating a new hugetlb as the target for > migration, that can unify the behavior and avoid breaking the per-node pool? Not as simple as that, because alloc_migration_target is used also from an user driven migration. -- Michal Hocko SUSE Labs