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 2CBB1C83F3E for ; Tue, 5 Sep 2023 12:41:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A57068D0002; Tue, 5 Sep 2023 08:41:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A06B18D0001; Tue, 5 Sep 2023 08:41:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F5828D0002; Tue, 5 Sep 2023 08:41:49 -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 7FC668D0001 for ; Tue, 5 Sep 2023 08:41:49 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 48B98140856 for ; Tue, 5 Sep 2023 12:41:49 +0000 (UTC) X-FDA: 81202505538.23.FEA4DC6 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf10.hostedemail.com (Postfix) with ESMTP id A40FFC0016 for ; Tue, 5 Sep 2023 12:41:44 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of yuancan@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=yuancan@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693917706; 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; bh=ZtQhqwTLmpkjSN/2jtmOEGUnaUvaI+rjFSTiB7mdkOQ=; b=synPKz1hMDoaNH5MQmgauSL+4kuLq0b4CmY0ivFtTk751+dUEhNO1aLcQDMANefSjpyhv0 HoXJ9y5pITzJDwTo4ljgrm2hyqRYWYFY2qxuSsRzKVfeaZeFW6ddDC1uRHwNNIWRRtmlw0 rg5b3l8tmmcpkoKrtpIfZ485+gOs0xI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693917706; a=rsa-sha256; cv=none; b=eBJCBnojTjUB6mMErBes1GW/dC+7H5B5PPqDw/nQT/8/AhEfGLlT3h0Th2cTL4H1D+pTjF s+f0oZRj3tbtjLYUukKnxAsThu8Du+W7/bH/gXe9EgSO6iNcL2vKXFV2UocAeCcLqBkpyh ktR1qlQlSo+a6ygLQ9DvpX6fUMcG6Qc= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=none; spf=pass (imf10.hostedemail.com: domain of yuancan@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=yuancan@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com Received: from dggpeml100024.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Rg4m53lmBzNn9R; Tue, 5 Sep 2023 20:37:57 +0800 (CST) Received: from [10.174.178.41] (10.174.178.41) by dggpeml100024.china.huawei.com (7.185.36.115) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.31; Tue, 5 Sep 2023 20:41:37 +0800 Message-ID: Date: Tue, 5 Sep 2023 20:41:36 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Subject: Re: [PATCH 1/2] mm: hugetlb_vmemmap: fix hugetlb page number decrease failed on movable nodes To: Muchun Song CC: Mike Kravetz , Andrew Morton , Linux-MM , References: <20230905031312.91929-1-yuancan@huawei.com> From: Yuan Can In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.178.41] X-ClientProxiedBy: dggems702-chm.china.huawei.com (10.3.19.179) To dggpeml100024.china.huawei.com (7.185.36.115) X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: A40FFC0016 X-Rspam-User: X-Stat-Signature: eed19hp61xfxyyt5eaj9b31w4fkoqf8t X-Rspamd-Server: rspam03 X-HE-Tag: 1693917704-67761 X-HE-Meta: U2FsdGVkX1/vZaQG6MNdLZX1phAGS9SL6qQe6DJRYS1kLHHYaaGo5yhY19CQx3PleBd5PRUf0MF8YBB6NMckKGzMMIXF5uIYRp6gxgAdHbPrq9qPggq01fivUodhN0jzDF03S108rT+si+OCwc+nRLhEAawlHjrH4leK7n3tTevHa3p8/kiyfBlK9qvTLsyC0w6z93MYJ85He/1PhNUG1t/lgTxaBVBXD5U8wMtPIhXMx5kt3GXdSnAHLQNZyW+quUEIh/eiweOKkDeSStC/mquAzYOTLlx1kX/qC7RF7r6TmXhz6ItyEIlCxXxBhIs181wSB/2283SFVDcEAucSXsd+9EjaZrmauSEXf0nf9IYq3xINppBPJr74omYT92TxsJ8UTJyMVW1WjhfN59DLqA1QIOOJ/Y5hY/oYhQnfZbaOV1eSKYY0gQDiY50QxRs9BWcc803hS8ipKxnHafmPpSC/InxBspgQFe1dCYAbsQQt+66dUjBuBbMVIuE8Sbsu/XCcaplaTufQ++GqDFoYKVSh5OWa9R7/ZXJJUEerOjMFb7PJtl9a2SDOuhh7MC1/GJFfCBOQnKqr5JIcQktQLMinon1BgnIzJNqBAMSIu+MtbB6U1DodnKfB7/hx4CYxcTjC0gECobYZyKA1vKEWnn9b8WI6y0JXflkt7ftsVvKOYlGVnWDAsk6m9PLZawqGfNpZHoHFKYNcQ2jGCfcxRj85zrac8n4xC/1wYGf4t249Sp4nTnWoNyT1NoJC8+k2+Wdedyj+Wbp+iUMAy+WlFUdPBg08Xh+eyTlOBC0bBzrrS2hon/ElruykXG5au+7/pf4o+8kcxGh5royTPL/tNn7wwdvT/YuGIyBQ/lz3thUy57v60ni5m2rQp0apBS3TGj5k/GdTo9F/HdKml1QZyqhb8HlWF1zsnmZWt+9FJjcyGDyT7eU+XqcBlsqV6tYUQHDFI+90MMdS3EIWhm+ ca1/Wb92 MMAcMrVhdauaeyPWbmokEbp5jkRjpNAiSXb5lgip2yr4kYWMgvDh70fu6nVqNw2OfCaHkUh2tm46mIndmFg5Pf7YZ0PuYTrDsJAn9zL1qvVqs08aGP4XlH2iedRBO8i6ftJzAJD2CAJIlDqMSDmWTPGyzyBbxqgNFoERmsmZW+yxwrGpy16t+UEyzC7WIJ+Fkmz/tcHNFjpiL5zE0YhgmMfYgDACWgA99JQpwkUxk/YqIxatObVOeKVW09dZeqo/YRU7RJT3mj6i87y4= 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: 在 2023/9/5 17:06, Muchun Song 写道: > >> On Sep 5, 2023, at 11:13, Yuan Can wrote: >> >> The decreasing of hugetlb pages number failed with the following message >> given: >> >> 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: >> ... >> >> 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 > 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. > >> releasing. With GFP_KERNEL and __GFP_THISNODE set, allocating from movable >> node is always failed. Fix this problem by removing __GFP_THISNODE. >> >> Signed-off-by: Yuan Can >> --- >> mm/hugetlb_vmemmap.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> 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 = GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_THISNODE; >> + gfp_t gfp_mask = GFP_KERNEL | __GFP_RETRY_MAYFAIL; > 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. > > Reviewed-by: Muchun Song > > Thanks. Thanks for the review, I will send the v2 patch with Fixes tag and your Reviewed-by soon. -- Best regards, Yuan Can