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 F06DDC83F2C for ; Tue, 5 Sep 2023 10:43:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 287F994000D; Tue, 5 Sep 2023 06:43:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 238718E001A; Tue, 5 Sep 2023 06:43:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 126AF94000D; Tue, 5 Sep 2023 06:43:12 -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 F35548E001A for ; Tue, 5 Sep 2023 06:43:11 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id BC4ECC0C42 for ; Tue, 5 Sep 2023 10:43:11 +0000 (UTC) X-FDA: 81202206582.25.0C8469E Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf20.hostedemail.com (Postfix) with ESMTP id 1828A1C0032 for ; Tue, 5 Sep 2023 10:43:08 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf20.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1693910589; 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=DQmzYSx22vw9ZBVRGuNvITNNDp3N8bjOCownluYKczA=; b=GcpcIr9DzRwk3e40rxu5MhT4i3RTuh/e2S6HYd7LpSFxYOoUA131kHhyp/zfW08/9s9A1s N9y8y16EAXbCQKIQ3IZu6urqEd5Y22Oa9ALHIrjgh2HAVCd6lszf7m1XOI9lxpHj3gkWMX /jh/i9EJgemd7tE1WrfwtCnzh0ulwzI= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf20.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693910589; a=rsa-sha256; cv=none; b=JcwqmJRVPZuN4HDYqZzwcBA94Mdf3LVDDlhT5cEFBX/3qgg3xPHs0/L4aRuur1perfeTxX gQgT+PG2ldTy/IawgdU3yZZugC8zIqSfrPV0I+lckz71DF7WOum13BJZQCzG1vwObtD2Vy aDa7+nyreIjvwtFvUb6VwyImdnXVCRs= Received: from dggpemm100001.china.huawei.com (unknown [172.30.72.54]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Rg27H56fvzGps9; Tue, 5 Sep 2023 18:39:23 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemm100001.china.huawei.com (7.185.36.93) 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 18:43:03 +0800 Message-ID: <74ea7825-d5a7-4a3e-9d1a-9721dba4d82d@huawei.com> Date: Tue, 5 Sep 2023 18:43:02 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] mm: hugetlb_vmemmap: fix hugetlb page number decrease failed on movable nodes Content-Language: en-US To: Muchun Song , Yuan Can CC: Mike Kravetz , Andrew Morton , Linux-MM References: <20230905031312.91929-1-yuancan@huawei.com> From: Kefeng Wang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To dggpemm100001.china.huawei.com (7.185.36.93) X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 1828A1C0032 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 3ua3syx8d1314qnapgfm8d48hbha93c8 X-HE-Tag: 1693910588-487916 X-HE-Meta: U2FsdGVkX1/ZayUIcbkqG89YtiTqa1OWF+wLmOcljvwb7lXmbuQEzobfKGC8M0iozP2nnyrdNiSIjKbYm7tUcmvh/UwlLuYBuFSRGjK317LtDU4Gtjsq5VwT2kuLEIqAMAx7O7HQDvOey5dRfy0uM9lHdUVh/66RlbOLV2m4KzfXqCgzBnLL4t2utGPI+70H9+dKxsPdZd6ScrYYeRfABHYVxCylqHo9hf5+jds6jH7tIewGRRPI1rlDlwIXq8zUa0HHT5niyGmu//mIvh5Z3Id03ZwxWXADxmWc2BRrHMhAuCnFSuJDehEEuTYrDDTINImJbxKWDuVdn+pptaZsx+sp2go8+ck4/a6HaSUVbcnfLhgYwV3qH0AhuoWbCXNyvhQUu/zS8D8SGxURuOAbpNTvu/tzNuewThg/ts0LgmngLP6qd0uOhZcrGE0AP2Fx2fSce4l3GMBfmOG0IPjfUpb3w5vEj10ueSyXycmZ4iKg42/ne+SOXveVgYA8R8k68UjzRwP+KbRPL/6UnGU89anbIhCqC70EF+/vNxyPYU4bjVECWQCtIQli2CkMx4iN5eTJ7thgq5rYh9swhoCBPyphhy9CrpEilMzOIQHtZXDHG7gAqb9hPcG0dzwUYPElYV4Ocb2cV2vd568hrL1kwPRU8LDiGao0HatAXKiPJruozMHZ4p5Ydl81d5eYAI3v+ig6+KAf7coBLPI286FiOErL8y1xL7To3Mno3MKZZ84tTeRpk4MlCP68Q7czNnLbH0nuhjs0NT1Vm+tHcx3Hq85aHRJpHu35n83qyaGWlZaOfStRy5srpsGoWJicKno5vI4idn+9DRfkYWCgUQgDn+f8LjwP8NQfwduCC8xaE9s96JygumziYd/ZpVdRw7Bmsbc5ESZgkwJDTeLpt/1HxWTc5H/ePOKxz8mAWNqbMZEV+QFejMXUYTPIGx0Q4T18FWdVCg+mqc3yPuWOktJ a9eYnGoT hnSYFshQ6OSbCNKQmxMX4jbn2yxMKNX56eRgCAAPlwJPZga26P+LRzvlp58O1dvMej7JhVRMXMGmku8PJsQlbrI0BJKjrGu0cckTsZTwT2xI+CerWVDeSJa/wsthowJVIzoz+joASzOpZiwrxi4euaE+mwxibAxB4hb75kBHHM5Qy6Eoo60fCEGGJR5yhpqPmm2vKJr9PiwyfBP7dIYvyER0zJldRErpV12Ej2nhg3I5bswWUD9d8Ug2ZbdtlmYD9P6iGtt1gGquYmfd4+zQGepiyh90aUdpn4pvlwA55nu13z8Y= 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 2023/9/5 17:06, Muchun Song wrote: > > >> 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. Should be ad2fa3717b74 ("mm: hugetlb: alloc the vmemmap pages associated with each HugeTLB page") >> >> 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. > >> unsigned long nr_pages = (end - start) >> PAGE_SHIFT; >> int nid = page_to_nid((struct page *)start); >> struct page *page, *next; >> -- >> 2.17.1 >> >> >