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 6F8CCC77B7D for ; Wed, 17 May 2023 06:07:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8172B900004; Wed, 17 May 2023 02:07:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7C6BD900003; Wed, 17 May 2023 02:07:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 69000900004; Wed, 17 May 2023 02:07:36 -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 59DBA900003 for ; Wed, 17 May 2023 02:07:36 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 17171C0452 for ; Wed, 17 May 2023 06:07:36 +0000 (UTC) X-FDA: 80798715312.04.34F6C55 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf27.hostedemail.com (Postfix) with ESMTP id 3046F4000C for ; Wed, 17 May 2023 06:07:32 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684303654; 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=20YAAy9lwv4ZakwN6+KtyDcCx6bJcro7yNus3Z+RrwA=; b=BfoVmyKNcGVEBfRx5zgFo4h7NNsiI2wUI4yiqu4oUe5LS7zBPPej72V6RPOBECkOPaYyhv dLD8pF96mJ2Qm+KjKPIAiava//3KPO7e9IaCz21QI9Fp8cNqS6hHouKMP6+BGohkRhz1WB 1zQa/kWdxglixd//FM/M5PoSzCLqf2s= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684303654; a=rsa-sha256; cv=none; b=U+kM9Jmgf1h1XMIJkit2l/hVhZ/Jsq80Y6yMn5c9w7C7gNGKmNXZ/5SloBkLt8+VsILD8M +NvAHDn3W8xdbLWah5LVXEsOXGUcwzTHJJ5vVlGn4/3XhzvEcY/9NoP2+6/8CEvytGWTno qXSJ+eWm4qEViBVdicqqAa2qZ/1iPf0= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9E5DE1FB; Tue, 16 May 2023 23:08:16 -0700 (PDT) Received: from [10.163.70.237] (unknown [10.163.70.237]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9CFC03F663; Tue, 16 May 2023 23:07:29 -0700 (PDT) Message-ID: <52fa3a4f-5467-7b68-334c-4280d3925b39@arm.com> Date: Wed, 17 May 2023 11:37:25 +0530 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v2] memblock: Add flags and nid info in memblock debugfs Content-Language: en-US To: Yuwei Guan , rppt@kernel.org, akpm@linux-foundation.org, tsahu@linux.ibm.com Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20230517025747.230-1-ssawgyw@gmail.com> From: Anshuman Khandual In-Reply-To: <20230517025747.230-1-ssawgyw@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: nea8f8ycbbe7ojiuwe3sm8f1gazsukas X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 3046F4000C X-Rspam-User: X-HE-Tag: 1684303652-682301 X-HE-Meta: U2FsdGVkX19g+9gOKO0FlxOmFKTfBV2oUVOPbRBqUQqrd8OsWCMSrh9wdSWudtdwUbrnHGj2ecRDi+AQ0EgEPwNGBMptyJinrFsIPlYw/8TtFZ4gLcbQKdcYj32tNij22KA1wsITrdcZ7rILn68FID6CLOUm4tHrVjt8yBUXyE3J3X8rgDmcGkVUEVBO+m+O1zZRuVX+Kx7xCKMkFVnrQGqmY9hx+dTjtTlsc/Z6VdNLfKh8XJGZ/V3EO5SAteE8cuB5/pCslYt2p7CWk4+mhEHQLn7oCkMYn2mBBhaKKW39MnXV8HEo3FG8h9LMDfbNZQN9MIK6omv7kopqpBKEBVnfyJIVeioEvNzpEcWqdGx1iW0IRHXpCx+ghBiU3degxG55hjmedQ99NV7PNvXdzSf/AlPc6ATqtZ/2hfwjgHrv84Kk+dGB1R1Rt9ecA9orXk3cksfUdMRukpDx1zUhA7WQahldQ1+Vu8GskyUJFksZOrNXMck5fsic36aE96qhbWOIete2JFO5FJ+jg0/cazEvb+VwsMp4bxSA5VE/RTRNkTwLJ3sDnlEIk5lczIke1VmeMz15pj7KW0BDK2k2Ki1EhAudwKXSZbosh8n5I13rr23NbLJW8m/QZW80v+aU6SW4PfZciEYFrgtsstTeYnZUmb4M/HvGGt4nzmLlNfcn8t39VB3Q5oEBzVyTKNJXquyBY0SayHvuNb6E5lgqaWS9LwRWIvUZUMA8hScB8IQz/7hdN/95N2HoAIbPbeZvU51cI6NBtYWX/KSRjqJYU/JcGro+lqv4eY9oL6TiBbAfNQWOFZ7UKmbexQjTgaErzGI0H+21skFjw4WIQeeuDZVWROWNbAc7kS012wv3jCNiRdMuDKTKdmPrWsV7QakUZmOT5RPAn570OhBU1AJ4r9LPbXQ1ybEguGVudz5Op1DFpQZm80LAu44LA40I2z7h8OZ02B+WjjMKKq1rh5Q l0IlSKlb q0cXZljNoQbRdlrPGs+BK/SX2EwBIG50zNMJhiqY68G38/JcbM6t+GBCis6AFnLzy0Sc5F7A/QIGz9tkBfNBVig6aPDe8ZBT+P3LufNtQNVStSRm+0OT5bxtBhGGO7VzbfYYulRkqNW/dUxix4+jaNNmK4A== 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 5/17/23 08:27, Yuwei Guan wrote: > Currently, the memblock debugfs can display the count of memblock_type and > the base and end of the reg. However, when the following scenario occurs, scenarios where the memblock flags or nid varies inside a single PA range ? I guess the commit message description here can be improved to accommodate such details. > the information in the existing debugfs cannot make it clear why the > address is not consecutive. > > For example, > cat /sys/kernel/debug/memblock/memory > 0: 0x0000000080000000..0x00000000901fffff > 1: 0x0000000090200000..0x00000000905fffff > 2: 0x0000000090600000..0x0000000092ffffff > 3: 0x0000000093000000..0x00000000973fffff > 4: 0x0000000097400000..0x00000000b71fffff > 5: 0x00000000c0000000..0x00000000dfffffff > 6: 0x00000000e2500000..0x00000000f87fffff > 7: 0x00000000f8800000..0x00000000fa7fffff > 8: 0x00000000fa800000..0x00000000fd3effff > 9: 0x00000000fd3f0000..0x00000000fd3fefff > 10: 0x00000000fd3ff000..0x00000000fd7fffff > 11: 0x00000000fd800000..0x00000000fd901fff > 12: 0x00000000fd902000..0x00000000fd909fff > 13: 0x00000000fd90a000..0x00000000fd90bfff > 14: 0x00000000fd90c000..0x00000000ffffffff > 15: 0x0000000880000000..0x0000000affffffff > > So we can add flags and nid to this debugfs. > > For example, > cat /sys/kernel/debug/memblock/memory > cnt base..end flags nid These markers ^^^ are not aligned properly, and also might not be required as well. > 0: 0x0000000080000000..0x00000000901fffff 0x0 0x0 > 1: 0x0000000090200000..0x00000000905fffff 0x4 0x0 > 2: 0x0000000090600000..0x0000000092ffffff 0x0 0x0 > 3: 0x0000000093000000..0x00000000973fffff 0x4 0x0 > 4: 0x0000000097400000..0x00000000b71fffff 0x0 0x0 > 5: 0x00000000c0000000..0x00000000dfffffff 0x0 0x0 > 6: 0x00000000e2500000..0x00000000f87fffff 0x0 0x0 > 7: 0x00000000f8800000..0x00000000fa7fffff 0x4 0x0 > 8: 0x00000000fa800000..0x00000000fd3effff 0x0 0x0 > 9: 0x00000000fd3f0000..0x00000000fd3fefff 0x4 0x0 > 10: 0x00000000fd3ff000..0x00000000fd7fffff 0x0 0x0 > 11: 0x00000000fd800000..0x00000000fd901fff 0x4 0x0 > 12: 0x00000000fd902000..0x00000000fd909fff 0x0 0x0 > 13: 0x00000000fd90a000..0x00000000fd90bfff 0x4 0x0 > 14: 0x00000000fd90c000..0x00000000ffffffff 0x0 0x0 > 15: 0x0000000880000000..0x0000000affffffff 0x0 0x0 > > Signed-off-by: Yuwei Guan > Reviewed-by: Tarun Sahu > --- > mm/memblock.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/mm/memblock.c b/mm/memblock.c > index 511d4783dcf1..b36fb6b31e0f 100644 > --- a/mm/memblock.c > +++ b/mm/memblock.c > @@ -2144,12 +2144,16 @@ static int memblock_debug_show(struct seq_file *m, void *private) > int i; > phys_addr_t end; > > + seq_puts(m, "cnt\tbase..end\tflags\tnid\n"); Please drop this. > + > for (i = 0; i < type->cnt; i++) { > reg = &type->regions[i]; > end = reg->base + reg->size - 1; > > - seq_printf(m, "%4d: ", i); > - seq_printf(m, "%pa..%pa\n", ®->base, &end); > + seq_printf(m, "%d:\t", i); Why drop the existing %4d formatting qualifier ? > + seq_printf(m, "%pa..%pa\t", ®->base, &end); > + seq_printf(m, "0x%x\t", reg->flags); Should there be ORed string values for each memblock flag ? enum memblock_flags { MEMBLOCK_NONE = 0x0, /* No special request */ MEMBLOCK_HOTPLUG = 0x1, /* hotpluggable region */ MEMBLOCK_MIRROR = 0x2, /* mirrored region */ MEMBLOCK_NOMAP = 0x4, /* don't add to kernel direct mapping */ MEMBLOCK_DRIVER_MANAGED = 0x8, /* always detected via a driver */ }; Something like NN | HT | MR | NM | DM ? > + seq_printf(m, "0x%x\n", memblock_get_region_node(reg)); > } > return 0; > }