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 78C61EB8FAD for ; Wed, 6 Sep 2023 03:00:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 80161900019; Tue, 5 Sep 2023 23:00:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B0FA8E0014; Tue, 5 Sep 2023 23:00:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C790900019; Tue, 5 Sep 2023 23:00:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 5E2518E0014 for ; Tue, 5 Sep 2023 23:00:51 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2525B80C32 for ; Wed, 6 Sep 2023 03:00:51 +0000 (UTC) X-FDA: 81204670302.14.D4CB0A3 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf03.hostedemail.com (Postfix) with ESMTP id B12322000D for ; Wed, 6 Sep 2023 03:00:46 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=none; spf=pass (imf03.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1693969249; a=rsa-sha256; cv=none; b=Gq6+TTJHK3v8dMwTvGj1LaX1H9BZS88TJg127k2R8DmjjV/72lUF8By1cvDEO/Lf0po83k gkoaHlOhcaQOYdafmhvmLMJpa4QevHTZdR078YATiWZ5D1n7i2mo6Mo0R5Sby1BfezAZVL uauL/wLd3MXlHr0GJ4dRd6c+6jwBmlI= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=none; spf=pass (imf03.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=1693969249; 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=Uhr+Po49CmMAZECzQ2IQi685UG525m0Uwfv7Mrr31Ac=; b=hL4chSq66R06vJaMMcB0iVtL7/C/z4f0CQ4SteObLydlvwK4sJFyAiZ5f/V5wHQjWOlLEx TEbS7aYQdHcV3UtWxpDee/p1igVoMFmBEuqrbLSlCF7w9NqthnArBDtI83cFVYXyKsvjL2 cW/vRtl3EjXBrZnUwjKN4xZ71ASIsa0= Received: from dggpeml100024.china.huawei.com (unknown [172.30.72.55]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4RgRqh0DWrzVkY1; Wed, 6 Sep 2023 10:57:20 +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; Wed, 6 Sep 2023 10:59:56 +0800 Message-ID: <69728eae-98bf-2168-f559-1d747d604699@huawei.com> Date: Wed, 6 Sep 2023 10:59:55 +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 , Mike Kravetz CC: Andrew Morton , Linux-MM , Kefeng Wang , David Hildenbrand , Michal Hocko References: <20230905031312.91929-1-yuancan@huawei.com> <20230906002814.GA3740@monkey> <204FB105-A6F6-4D8A-9311-F721B6567AD0@linux.dev> From: Yuan Can In-Reply-To: <204FB105-A6F6-4D8A-9311-F721B6567AD0@linux.dev> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.178.41] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpeml100024.china.huawei.com (7.185.36.115) X-CFilter-Loop: Reflected X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: B12322000D X-Stat-Signature: wrwyd93896xyyjyekumfdcwads7gw44t X-HE-Tag: 1693969246-983071 X-HE-Meta: U2FsdGVkX1+l7abU7YRMoOHcTr7rf+taDlRrwKZlcpc3BybzKpzprF7cLI6NVp6ZHP6B1i22u+Y2CCB4rmjZ0B+7fMOKSBN+myXn/9TCPpfUjQLJTtvCehQjpaJD0M2+ozvMSRxOvom4wuFXkTYIB4IgvR96U4U1YkKcgnAg4pSJc5s18dQah+p3yzyUX9fP3w3sAbn+9w82jrcfCFmtZvUHxeY3fKjgE2lOpm8d45e8isltuk6nLPMFrt4ZxuSQpapMtRqkcES+m9N7CtHbxExu7m0L224rdQL9is13wcMNtnkUCCKl+G9NeBjlqTjWa+wsLIo1fPzld8OceyzCFPnyM+qT3KIOCMPygzCQUwTfy8FnjUI83/RLSFlT2/VwT/Wb181C3lnQxIVOROQfVVWgMmEqN6wdeO6iHLI1658Qvbto36rOxE15E4w6n8sgyfTj8FgzyjWah2nuVxwE9fq40SXSDrcfleVpQXJlOD/Q/cKkFKRhy23tFVOPc7+lXBkRg+i5juU+PoOhECYjkHHJFM5HXHhoSN2VFh9AGT4jfxqPPFlMAAC3JNuGIxHCjnMjIseu+Z/Nua+jRuyYvzHRNEIT1O+IT/8Bt+TbdkfRWNjAjm6twtXDZ6TYL9uq//CoAwj6NQBlZSCsPSzWx4C2j7zyP+X4lA8Lhs2cNwg3ZJOGUwIENWQVpyV2JyrEYtiB7S4er2xTo6xLtXD/sjKC1wsyMN/m3U5rUxcJwJsRYHC/zFCJ+kk+ef2EpapgGSeH7WcgyybbVhCCAW0fkXRtzrPO2r4uL8i+2Owy3DTtXJ/08VikM8PYxhjPADrJwBLejh80j593oWe3gt2npXkD4JtCI+KRogM0ndmt6htyLbAdklKDNa0V2ZT8qaeN9b+MVPJJM5e1iWxesXbZGeDk5Fyx/sSbrWA2avFclHC76twnmyrLMiI72y5eOsekfTHIvi55FbWxB8yH1Gc L5md6ILU d4+k5mjjUVyyRhPwR+T1qZ+LMTQKySO32Jryvf96B7oBKDXCvrzdzVxJRUJaCBkGJTxjiejEtYGCKrfworiqY9xf0uv+VkH760jfhO3laNqIXwyP2wxk6CLm2ZeYeO1wwCG+Qs4+08iiSoZy2QnOHjRQO97S/lJ1aVgwBM3ZTxDGajeRw58elvLY0tpnAx2mdpJ0MRGo8XFJwObbomkY/CCH6yioWHVIjFKY5 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/6 10:32, Muchun Song 写道: > >> On Sep 6, 2023, at 08:28, Mike Kravetz wrote: >> >> On 09/05/23 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. >>> >> 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. >> >> 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. Sure, let me send another patch passing __GFP_NOWARN. -- Best regards, Yuan Can