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 32197EB8FA8 for ; Wed, 6 Sep 2023 02:33:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4DDFF900012; Tue, 5 Sep 2023 22:33:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 48DDE8E0014; Tue, 5 Sep 2023 22:33:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 35578900012; Tue, 5 Sep 2023 22:33:37 -0400 (EDT) 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 266B28E0014 for ; Tue, 5 Sep 2023 22:33:37 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D7F06A0842 for ; Wed, 6 Sep 2023 02:33:36 +0000 (UTC) X-FDA: 81204601632.23.DDAF82E Received: from out-215.mta0.migadu.com (out-215.mta0.migadu.com [91.218.175.215]) by imf26.hostedemail.com (Postfix) with ESMTP id E7676140005 for ; Wed, 6 Sep 2023 02:33:34 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=e5IsmrOC; spf=pass (imf26.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.215 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693967615; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=kB7rvmwQbMY5GdJulCikcAV/pTLDb63UWtjmMIh4PbA=; b=VGdoBKg02+WWbqEcfmMfTBBsICoJSP74u7p7yH2svCM1pTtWM6xKQC1yMzyAWSRAwhnXWA gCETKyiHpuVVj9NXlTs6SHFwL2ZxjbswbIQj/40De4sYKtOo0fpXppHevWsp9kSGkKnAiZ u4F67w+FxW/BnFwUz+IV5icVoP5SNTc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693967615; a=rsa-sha256; cv=none; b=R+tmjAFu+eu4TU6+eTIhb/2ZBMkXBOzlmDQ4q86Im1aJt4/seZltBAim9nPF/qqr3mQx0s pTQI1voA1QQqULrJA9G/Ks5oSx5361pUqsyuOFusDkPEZ4ZivLlHCvwng4rDCaaox3XKys 3KFa6lKHRRLAmtL0rjRVsg3fXa85JJk= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=e5IsmrOC; spf=pass (imf26.hostedemail.com: domain of muchun.song@linux.dev designates 91.218.175.215 as permitted sender) smtp.mailfrom=muchun.song@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Content-Type: text/plain; charset=us-ascii DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1693967612; h=from:from: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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kB7rvmwQbMY5GdJulCikcAV/pTLDb63UWtjmMIh4PbA=; b=e5IsmrOC5TgOdNex3XQqSzOwFFIyEkRB7tDODr0coTXbrZKMHllT/AKu5jtboGJ8UrkeNw /Ob6Xc+tP/SToHFoiOqUq/iIa+RsSxcHzU3vXHl2xFYlyRbdvNgpZAIQ3uHZBWZpgeC+og 39XPgBVhd10b+PwqfduhDwFRyI2ochE= Mime-Version: 1.0 Subject: Re: [PATCH 1/2] mm: hugetlb_vmemmap: fix hugetlb page number decrease failed on movable nodes X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Muchun Song In-Reply-To: <20230906002814.GA3740@monkey> Date: Wed, 6 Sep 2023 10:32:50 +0800 Cc: Yuan Can , Andrew Morton , Linux-MM , Kefeng Wang , David Hildenbrand , Michal Hocko Content-Transfer-Encoding: quoted-printable Message-Id: <204FB105-A6F6-4D8A-9311-F721B6567AD0@linux.dev> References: <20230905031312.91929-1-yuancan@huawei.com> <20230906002814.GA3740@monkey> To: Mike Kravetz X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: E7676140005 X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 5xdx9xa8jaan9n3t4utxw36m88iamtng X-HE-Tag: 1693967614-454436 X-HE-Meta: U2FsdGVkX18U7donv5o0MOUDRUDNPKmdG3WGCPEraXvuL5eIDQJUYpiuc2KOOSzUnd1H93eThn/ZIGB2l2luPvdTjtLB4TEM12mFTx0T/VtM95/lum0njCwTOa2V6ajUdyFVJP+izkqShFWY0kHkhswI1AXciEOYY2KZXkheRKRevzwMnPiOxKZXlu2g3XVIRyj3z1VZxnjbILtBm0e/XpWVkM4Up10XNzkp6sT1/sUjpM8was06CjtvFv032B/aeco6rNjdmdgAbulTESsSC40JZcQcl4RWJt0vPYdYn2lecC8QnTm08FlxSti8Ye/XNfiNuDwWRIG5XruOp0H5rz5BYPSpGayCNXI9wgbrB8pYtGbdECy+nucQ6a+V+rFouV6gBb+WVSyAxvvwRuqHw39P254KhwByoLip0TkHbqzvjJRqYhq9jH1Q0xeqfmf21ScmHHsiucw2bXzvzVeupjZ0FqvyVDkNVosAj44XzTt8sVZKobJut+AcONCwSKssz1qDC75Me0UZ5v2iLGAF1wQl+lTNtW9w1BkBq/rQ7LpJl/ule1jo9L7hO7CnGG6mNE9e5f8gBgIi1h0kRkZMQHoCrQw2iKFba7b4cFnG5vUkNuWCQn4OQF/2IamYUJO2389QuWus9A1Bo6Tqg/SXAMvG5mo+bXQS4tnV+YFAWF39C2tTQlrWm+kZs3UJQCarXMvKYZ+W/20Rj5z0OLFjSKZJNLPAsimajCns604cPNdaxrEmT7IF+Llt/ACDmIKI2dOixFibq+/rKHBaWWmP2QtZzCVXUBOEHTo0IOwnyaMNnwof/mdjSahnlE5zUXZnlC80vyMSYdqbeXyJItp8q7+RwjSOhBmHNn6MrPH+scKLdEGeMZI+nSmSw7R8VNchLAj/wwngj3Ma31G6g79MatsO6ftJ/1H96Dt0Q+4ut6AWDqy7z+eZOSm1N+Dkt+hzRpWZPIFDk0ktNRKtDLM WsY4pF83 ip32cLKkSU9KqGffwUa+GXQCo2tfYqf4SMe50FrhF6b6tbOaFg+u6yhi35XqimhjImHyZpRUpPHGAaIDGzgtwVWgN6as7iVtueyOxe35Lxf5CSDzKXpVhsY7aCeobGKKZV9pjXhICpz7A4Z8yhin7J0zXEfn/fT0yqrbA6mhvbB1YQDjo/aIlVUFxQZDdAuRUuHdztTxlb1DnnFi+an0KUDM/qt3BvIJcxPW2cXQ1y8aOzXRPo0flkGonfrqbZ3g104X/QCq/VH6QrLM= 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: > On Sep 6, 2023, at 08:28, Mike Kravetz = wrote: >=20 > On 09/05/23 17:06, Muchun Song wrote: >>=20 >>=20 >>> On Sep 5, 2023, at 11:13, Yuan Can wrote: >>>=20 >>> The decreasing of hugetlb pages number failed with the following = message >>> given: >>>=20 >>> sh: page allocation failure: order:0, = mode:0x204cc0(GFP_KERNEL|__GFP_RETRY_MAYFAIL|__GFP_THISNODE) >>> CPU: 1 PID: 112 Comm: sh Not tainted 6.5.0-rc7-... #45 >>> Hardware name: linux,dummy-virt (DT) >>> Call trace: >>> dump_backtrace.part.6+0x84/0xe4 >>> show_stack+0x18/0x24 >>> dump_stack_lvl+0x48/0x60 >>> dump_stack+0x18/0x24 >>> warn_alloc+0x100/0x1bc >>> __alloc_pages_slowpath.constprop.107+0xa40/0xad8 >>> __alloc_pages+0x244/0x2d0 >>> hugetlb_vmemmap_restore+0x104/0x1e4 >>> __update_and_free_hugetlb_folio+0x44/0x1f4 >>> update_and_free_hugetlb_folio+0x20/0x68 >>> update_and_free_pages_bulk+0x4c/0xac >>> set_max_huge_pages+0x198/0x334 >>> nr_hugepages_store_common+0x118/0x178 >>> nr_hugepages_store+0x18/0x24 >>> kobj_attr_store+0x18/0x2c >>> sysfs_kf_write+0x40/0x54 >>> kernfs_fop_write_iter+0x164/0x1dc >>> vfs_write+0x3a8/0x460 >>> ksys_write+0x6c/0x100 >>> __arm64_sys_write+0x1c/0x28 >>> invoke_syscall+0x44/0x100 >>> el0_svc_common.constprop.1+0x6c/0xe4 >>> do_el0_svc+0x38/0x94 >>> el0_svc+0x28/0x74 >>> el0t_64_sync_handler+0xa0/0xc4 >>> el0t_64_sync+0x174/0x178 >>> Mem-Info: >>> ... >>>=20 >>> The reason is that the hugetlb pages being released are allocated = from >>> movable nodes, and with hugetlb_optimize_vmemmap enabled, vmemmap = pages >>> need to be allocated from the same node during the hugetlb pages >>=20 >> Thanks for your fix, I think it should be a real word issue, it's = better >> to add a Fixes tag to indicate backporting. Thanks. >>=20 >=20 > I thought we might get get the same error (Unable to allocate on = movable > node) when creating the hugetlb page. Why? Because we replace the = head > vmemmap page. However, I see that failure to allocate there is not a > fatal error and we fallback to the currently mapped page. We also = pass > __GFP_NOWARN to that allocation attempt so there will be no report of = the > failure. >=20 > We might want to change this as well? I think yes. I also thought about this yesterday, but I think this one is not a fetal error, it should be an improvement patch. So it is better not to fold this change into this patch (a bug fix one). Thanks. >=20 >>> releasing. With GFP_KERNEL and __GFP_THISNODE set, allocating from = movable >>> node is always failed. Fix this problem by removing __GFP_THISNODE. >>>=20 >>> Signed-off-by: Yuan Can >>> --- >>> mm/hugetlb_vmemmap.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>>=20 >>> diff --git a/mm/hugetlb_vmemmap.c b/mm/hugetlb_vmemmap.c >>> index c2007ef5e9b0..0485e471d224 100644 >>> --- a/mm/hugetlb_vmemmap.c >>> +++ b/mm/hugetlb_vmemmap.c >>> @@ -386,7 +386,7 @@ static int vmemmap_remap_free(unsigned long = start, unsigned long end, >>> static int alloc_vmemmap_page_list(unsigned long start, unsigned = long end, >>> struct list_head *list) >>> { >>> - gfp_t gfp_mask =3D GFP_KERNEL | __GFP_RETRY_MAYFAIL | = __GFP_THISNODE; >>> + gfp_t gfp_mask =3D GFP_KERNEL | __GFP_RETRY_MAYFAIL; >>=20 >> There is a little change for non-movable case after this change, we = fist try >> to allocate memory from the preferred node (it is same as original), = if it >> fails, it fallbacks to other nodes now. For me, it makes sense. At = least, those >> huge pages could be freed once other nodes could satisfy the = allocation of >> vmemmap pages. >>=20 >> Reviewed-by: Muchun Song >=20 > This looks reasonable to me as well. >=20 > Cc'ing David and Michal as they are expert in hotplug. > --=20 > Mike Kravetz >=20 >>=20 >> Thanks. >>=20 >>> unsigned long nr_pages =3D (end - start) >> PAGE_SHIFT; >>> int nid =3D page_to_nid((struct page *)start); >>> struct page *page, *next; >>> --=20 >>> 2.17.1