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 01700C77B7A for ; Wed, 24 May 2023 15:34:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9457A90001A; Wed, 24 May 2023 11:34:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8F5C7900007; Wed, 24 May 2023 11:34:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7E44C90001A; Wed, 24 May 2023 11:34:08 -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 6FBCB900007 for ; Wed, 24 May 2023 11:34:08 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 3BD52140B27 for ; Wed, 24 May 2023 15:34:08 +0000 (UTC) X-FDA: 80825544576.14.028F803 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf18.hostedemail.com (Postfix) with ESMTP id 0B2791C0012 for ; Wed, 24 May 2023 15:34:05 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=QpERaxuD; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf18.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684942446; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=G53y9yfniOhg6b6FKScfX8bB66tuj4Dl2zWbovbzpXk=; b=IDp0uCObkAFiq434hTy0ibn80RKxZuqHxmAbMnr8RvCrdRFIxO24h9nhENV0773zW2+jXA uPiy9XJQCxUMrtviRn6x4dXxOEEVUDVwnDFDdLGegB0cP8NsTn2gQJQpI+xX+jW6pT5ZFT UnOGDNOlyo7zbtzoTodMDfplpT2KxyM= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=QpERaxuD; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf18.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684942446; a=rsa-sha256; cv=none; b=N0nEi01qRZZfCXgiqX1IjI9RfpACoNL2Qb0n6GqAGffd0YKfmmGIr7/VcJBimEkCEqUeCX is0MVH4Nm84TZ1G0UpwxWvcV+6+z0aRrwz6pvBVygsOMQ0/kj7VuoCFAH31k8W0Bc5Nt/r R262HRnIsDeUKiMgguQtQKpydjijXNY= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id AAF7863E6C; Wed, 24 May 2023 15:34:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 01583C43443; Wed, 24 May 2023 15:34:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684942444; bh=4QHC/7RI05eUKQuxt6iIEos2VGTGOenDuE0rDWP+VkA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QpERaxuDyehcZp34bqas11QKRDScHrvuDKvxWWCqCmr17nIpk/cueE23t4irG3Gj9 jbIb1YF2N4dUHPzSmDMvOw6tSVq7pCV9BmRY1ZLR88jRqsyt3MfTwgkkfyQTCE+gEN U7Le1buCQ8SegwzW++ObXTO2fcbMBfmWZbvfd2tky5unxwkXACCI+v//RuC0EPM++d zn/Mb5jYq2dv2zN1fWx+zsNBzsE1IYIJTei1cedtlWGZ6fF7Yh7Vj6Jkk77/IfiuK8 W0phk87kHtb0GORlPVc7xwL+6eXpkOxKvnE32oJ/jXiMsdGXLx10Be9judm2WRLs6/ /yfb90kE2jTVA== Date: Wed, 24 May 2023 18:33:44 +0300 From: Mike Rapoport To: Kefeng Wang Cc: Anshuman Khandual , 20230519105321.333-1-ssawgyw@gmail.com, Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, tsahu@linux.ibm.com, ssawgyw@gmail.com Subject: Re: [PATCH] memblock: update numa node of memblk reserved type Message-ID: <20230524153344.GM4967@kernel.org> References: <20230523115708.195597-1-wangkefeng.wang@huawei.com> <03cdccc3-8b8a-d972-bbad-d60966e59ca9@arm.com> <4eb83d16-58ed-9f09-4308-f0f786580257@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4eb83d16-58ed-9f09-4308-f0f786580257@huawei.com> X-Rspam-User: X-Stat-Signature: j5bda9wtppr5j3qrs1s41uq49nb7nwbj X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 0B2791C0012 X-HE-Tag: 1684942445-261572 X-HE-Meta: U2FsdGVkX1/ic7DDSIvTprd5ur/Lf77Obpxw5jCx9P/GsTeJodZXfQ58bIStP9Aaqm4t7AKUxQBJDu0emxYaywYmSvScsGjbrJ0Bqi4nWQpSd1ianACMsgWu+4yuH94nZrEHJlcSj/1PnvUtUGIBmpPl4CFe/QFvqvOb6E0t2tDS/XEvEyIGZEQKEiAlc9eA/4SAhooWNaVrbknR14We9US9Gf5q3DwhAa3cwMVxckIUeX6yM41KK++zGF33SNTPEOe2+nCFtQutRfrOwAwqLpvdAguS9O0A74ZLCzE5XojkiJURNq65LvIQ5qFB6pKQailHqNVfjF3ctCFytqAogedyJlFLhMD6m5Tr5Y4SDufVF2O2ZMR0rAjN8edRqsSy0/kTsQsgT7WWPFqnkFYacvF8itWZQf3KXchllXGvsk0jxf5IaNggq/yKViJUKC4VcJHdM2vVQCoQD2D/Mmpn/OELTy9smOwW+vucXQSbOHdyqU+VgOq+aE1G7TFqOOIKP0L5LGSLWDE1qrcTkw4jFSlyegay1qMyxb48/WOULJW0jX0ihOKnC7+XxIHC066Ct9ztDRDcxIk5hwZ1gtEb7WH3iGuJA82LZoKJec1XW7+gXtAelbCCrWr4OXZg88AoPX0Ft0k35EauAD2Wlpbg1ij4gCwtVlTNh2mITuyg9IGsTDVhqnQU+8rPQ509iuLNUwIU4yURXwuGqxIH8wbk+1btOxyR8wicoigfHVBqmHpUHn5LXPCbxFbVzhh4XIZOFOsnAHvTMzm1NTwdMnClxWP9+ZGUw90fpqgiUUgNSPfuC5sk3pS0gjok5o0nIbIzZwuhtrs+rKYOO35l7OKS4PpxYIu404e3V3qyBmVR4/errTYv7keNfnS/PN4t6PbUUgfJbNWUwLMt4SjHx5rI7PVntCS/xphiyk48Xk9ZdHWxA+58OFT3JPd+E+599BFsp6Gw9rFn7CVL5Wkfifj P+ApoAXF wXugle9CUrEP5YuWtqxsNIUlto1/1IjYIFQbp8FlC2fZ6IudoOYoEOgAjSc9/0s/1y1xRlQAPzArRywLrWa5ef+5dFTBBMTmBUkFg+q5lIloEHLcHXM1Dbr1Fm9S616yVmu7s9fzFCfTmmzsh2HM7NKlFdO2fzbSx+pQABKQImV8xFS2Qk5hGHXVV+nSQqUxfPEVWr51Esz42Fi1eiN9utbM434cyxa3EG9eltI8vMBv0BRPNlhsgC3X321a5ORWDSvHBOrRbiQGsc66LCbJMXWCc9ZjgqEmPeQP3JgRaFuY5iKvIXiGVWBUsLN3S5x3srnsXiQqSTX5MYzvDeVKjrRORVC9tFIdzWC9+k0L9QVhvikv0VxgImLFs6ih6WSFzKWtW 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 Wed, May 24, 2023 at 02:47:26PM +0800, Kefeng Wang wrote: > > On 2023/5/24 12:59, Anshuman Khandual wrote: > > > > On 5/23/23 17:27, Kefeng Wang wrote: > > > The numa node of memblk reserved type is wrong, it could update > > > according to the numa node information from memblk memory type, > > > let's fix it. > > > > Indeed it's wrong at present and can be verified from sysfs file > > (/sys/kernel/debug/memblock/reserved) accessed in user space. > > Yes, both memblock_dump() and sysfs show wrong value. > > > > > > > > Signed-off-by: Kefeng Wang > > > --- > > > mm/memblock.c | 25 +++++++++++++++++++++++++ > > > 1 file changed, 25 insertions(+) > > > > > > diff --git a/mm/memblock.c b/mm/memblock.c > > > index a50447d970ef..45a0781cda31 100644 > > > --- a/mm/memblock.c > > > +++ b/mm/memblock.c > > > @@ -1922,6 +1922,28 @@ phys_addr_t __init_memblock memblock_get_current_limit(void) > > > return memblock.current_limit; > > > } > > > +static void __init_memblock memblock_reserved_update_node(void) > > > +{ > > > + struct memblock_region *rgn; > > > + phys_addr_t base, end, size; > > > + int ret; > > > + > > > + if (!IS_ENABLED(CONFIG_NUMA)) > > > + return; > > > + > > > + for_each_mem_region(rgn) { > > > + base = rgn->base; > > > + size = rgn->size; > > > + end = base + size - 1; > > > + > > > + ret = memblock_set_node(base, size, &memblock.reserved, > > > + memblock_get_region_node(rgn)); > > > + if (ret) > > > + pr_err("memblock: Failed to update reserved [%pa-%pa] node", > > > + &base, &end); > > > + } > > > +} > > > + > > > static void __init_memblock memblock_dump(struct memblock_type *type) > > > { > > > phys_addr_t base, end, size; > > > @@ -1955,6 +1977,7 @@ static void __init_memblock __memblock_dump_all(void) > > > &memblock.memory.total_size, > > > &memblock.reserved.total_size); > > > + memblock_reserved_update_node(); > > > > __memblock_dump_all() gets called only when memblock_debug is enabled. > > This helper should be called directly inside memblock_dump_all() right > > at the beginning, regardless of memblock_debug. > > This is my first though, but I found there are still many memblock_alloc and > memblock_reserve after memblock_dump_all(), so I update it twice, > > 1) __memblock_dump_all() > 2) memblock_debug_show() > > and without the above two interface, no one care about the reserved node > info, so I put memblock_reserved_update_node into __memblock_dump_all(). We don't care about the reserved node info and __memblock_dump_all() actually does not print node info for reserved regions unless somebody explicitly sets the node id on a reserved memory. So instead of updating reserved memory node info I'd rather avoid printing it in debugfs. > > > #ifdef CONFIG_HAVE_MEMBLOCK_PHYS_MAP > > > @@ -2196,6 +2219,8 @@ static int memblock_debug_show(struct seq_file *m, void *private) > > > unsigned int count = ARRAY_SIZE(flagname); > > > phys_addr_t end; > > > + memblock_reserved_update_node(); > > > + > > > > > This is redundant, should be dropped. Reserved memblock ranges need not > > be scanned, each time the sysfs file is accessed from user space. > > Yes, it's better to move it into memblock_init_debugfs(), > which only called once. > > > -- Sincerely yours, Mike.