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 0024BC433F5 for ; Sat, 2 Apr 2022 02:37:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3EFC86B0071; Fri, 1 Apr 2022 22:37:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 377C96B0072; Fri, 1 Apr 2022 22:37:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F31A6B0073; Fri, 1 Apr 2022 22:37:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0235.hostedemail.com [216.40.44.235]) by kanga.kvack.org (Postfix) with ESMTP id 0C0A36B0071 for ; Fri, 1 Apr 2022 22:37:15 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id B2D77183525CA for ; Sat, 2 Apr 2022 02:37:04 +0000 (UTC) X-FDA: 79310376768.16.427E74B Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf04.hostedemail.com (Postfix) with ESMTP id 9CDF64000F for ; Sat, 2 Apr 2022 02:37:03 +0000 (UTC) Received: from kwepemi500004.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4KVh3C1kL4zgYK5; Sat, 2 Apr 2022 10:35:19 +0800 (CST) Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemi500004.china.huawei.com (7.221.188.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Sat, 2 Apr 2022 10:36:59 +0800 Received: from [10.174.179.19] (10.174.179.19) by kwepemm600017.china.huawei.com (7.193.23.234) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Sat, 2 Apr 2022 10:36:59 +0800 Message-ID: <6900c697-2eaa-9e91-4d37-7a11c71d021f@huawei.com> Date: Sat, 2 Apr 2022 10:36:58 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: [PATCH v2 1/2] hugetlb: Fix hugepages_setup when deal with pernode Content-Language: en-US To: David Hildenbrand , , , , , , References: <20220401101232.2790280-1-liupeng256@huawei.com> <20220401101232.2790280-2-liupeng256@huawei.com> <0aefbc18-4232-0bae-b37a-d4c6995e3d00@redhat.com> From: "liupeng (DM)" In-Reply-To: <0aefbc18-4232-0bae-b37a-d4c6995e3d00@redhat.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.174.179.19] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To kwepemm600017.china.huawei.com (7.193.23.234) X-CFilter-Loop: Reflected X-Stat-Signature: 1tgyhz5483nf3dw6mh5h5ou5anxn5qxz Authentication-Results: imf04.hostedemail.com; dkim=none; spf=pass (imf04.hostedemail.com: domain of liupeng256@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=liupeng256@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 9CDF64000F X-HE-Tag: 1648867023-12451 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 2022/4/1 18:43, David Hildenbrand wrote: > On 01.04.22 12:12, Peng Liu wrote: >> Hugepages can be specified to pernode since "hugetlbfs: extend >> the definition of hugepages parameter to support node allocation", >> but the following problem is observed. >> >> Confusing behavior is observed when both 1G and 2M hugepage is set >> after "numa=off". >> cmdline hugepage settings: >> hugepagesz=1G hugepages=0:3,1:3 >> hugepagesz=2M hugepages=0:1024,1:1024 >> results: >> HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages >> HugeTLB registered 2.00 MiB page size, pre-allocated 1024 pages >> >> Furthermore, confusing behavior can be also observed when invalid >> node behind valid node. >> >> To fix this, hugetlb_hstate_alloc_pages should be called even when >> hugepages_setup going to invalid. > Shouldn't we bail out if someone requests node-specific allocations but > we are not running with NUMA? > > What's the result after your change? > >> Cc: > I am not sure if this is really stable material. This change will make 1G-huge-page consistent with 2M-huge-page when an invalid node is configured. After this patch, all per node huge pages will allocate until an invalid node. Thus, the basic question is "what will lead to an invalid node". 1) Some debugging and test cases as Mike suggested. 2) When part of physical memory or cpu is broken and bios not report the node with physical damage, but still use the original grub.