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 E2EE5C433EF for ; Wed, 8 Jun 2022 01:26:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6FA876B0071; Tue, 7 Jun 2022 21:26:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 682456B0072; Tue, 7 Jun 2022 21:26:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 54A516B0073; Tue, 7 Jun 2022 21:26:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 3EC5B6B0071 for ; Tue, 7 Jun 2022 21:26:44 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 18FEC6140F for ; Wed, 8 Jun 2022 01:26:44 +0000 (UTC) X-FDA: 79553329128.03.7BE4E03 Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by imf19.hostedemail.com (Postfix) with ESMTP id 509A01A0012 for ; Wed, 8 Jun 2022 01:26:42 +0000 (UTC) Received: from dggpemm500020.china.huawei.com (unknown [172.30.72.55]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4LHqJv1XQ4z1KH3V; Wed, 8 Jun 2022 09:24:47 +0800 (CST) Received: from dggpemm500014.china.huawei.com (7.185.36.153) by dggpemm500020.china.huawei.com (7.185.36.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 8 Jun 2022 09:26:35 +0800 Received: from [10.174.178.120] (10.174.178.120) by dggpemm500014.china.huawei.com (7.185.36.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Wed, 8 Jun 2022 09:26:33 +0800 Message-ID: Date: Wed, 8 Jun 2022 09:26:33 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 From: mawupeng Subject: Re: [PATCH v3 4/6] mm: Demote warning message in vmemmap_verify() to debug level To: , , , , CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , References: <20220607093805.1354256-1-mawupeng1@huawei.com> <20220607093805.1354256-5-mawupeng1@huawei.com> In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.178.120] X-ClientProxiedBy: dggems701-chm.china.huawei.com (10.3.19.178) To dggpemm500014.china.huawei.com (7.185.36.153) X-CFilter-Loop: Reflected X-Stat-Signature: jfagpf18tdwoy8f6tx6zfop9ojwchsgh X-Rspam-User: Authentication-Results: imf19.hostedemail.com; dkim=none; spf=pass (imf19.hostedemail.com: domain of mawupeng1@huawei.com designates 45.249.212.255 as permitted sender) smtp.mailfrom=mawupeng1@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 509A01A0012 X-HE-Tag: 1654651602-721266 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: 在 2022/6/7 20:25, David Hildenbrand 写道: > On 07.06.22 11:38, Wupeng Ma wrote: >> From: Ma Wupeng >> >> For a system only have limited mirrored memory or some numa node without >> mirrored memory, the per node vmemmap page_structs prefer to allocate >> memory from mirrored region, which will lead to vmemmap_verify() in >> vmemmap_populate_basepages() report lots of warning message. >> >> This patch demote the "potential offnode page_structs" warning messages >> to debug level to avoid a very long print during bootup. >> >> Signed-off-by: Ma Wupeng >> --- >> mm/sparse-vmemmap.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c >> index f4fa61dbbee3..78debdb89eb1 100644 >> --- a/mm/sparse-vmemmap.c >> +++ b/mm/sparse-vmemmap.c >> @@ -528,7 +528,7 @@ void __meminit vmemmap_verify(pte_t *pte, int node, >> int actual_node = early_pfn_to_nid(pfn); >> >> if (node_distance(actual_node, node) > LOCAL_DISTANCE) >> - pr_warn("[%lx-%lx] potential offnode page_structs\n", >> + pr_debug("[%lx-%lx] potential offnode page_structs\n", >> start, end - 1); >> } >> > > This will possibly hide it in environments where this might indeed > indicate performance issues. > > What about a pr_warn_once()? > Sure. This will works. We can certainly use a pr_warn_once().