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 530D8C7EE23 for ; Thu, 18 May 2023 14:10:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8A0FD900004; Thu, 18 May 2023 10:10:08 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 850B0900003; Thu, 18 May 2023 10:10:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7182D900004; Thu, 18 May 2023 10:10:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 638F9900003 for ; Thu, 18 May 2023 10:10:08 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 10DFEC07FB for ; Thu, 18 May 2023 14:10:08 +0000 (UTC) X-FDA: 80803560096.23.C7BB630 Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com [209.85.208.170]) by imf11.hostedemail.com (Postfix) with ESMTP id 0CABA400EB for ; Thu, 18 May 2023 14:05:49 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=GS7wjn4P; spf=pass (imf11.hostedemail.com: domain of ssawgyw@gmail.com designates 209.85.208.170 as permitted sender) smtp.mailfrom=ssawgyw@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684418750; 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:dkim-signature; bh=b7TdkTgtpE/I5dsPVP8TWDXytE/RrW+PwM2s8w+gwFY=; b=57gBg0BKgF60N7HsCIqNrH8zDq7+nnbLPXuUtzzToqOvxbL4fvutRsThC/76k0UjCK+Vds 7RjMqQKqlDFHTHeC8dlHvXL1ocy7ThYUZ9yR6opea1CXCxI0W4c5CblWynoytUFESgx77Z Hq5DRJRPASduz4wBi/6OxzDyZmYCI6M= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=GS7wjn4P; spf=pass (imf11.hostedemail.com: domain of ssawgyw@gmail.com designates 209.85.208.170 as permitted sender) smtp.mailfrom=ssawgyw@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684418750; a=rsa-sha256; cv=none; b=rfPQUQLpruRkC3mfypese4Zhqhe/jzzNYEGRnPttkerB7hHr7baFJvxBf9Zm+Jlv6W2i4W mGpL65N20fuBsTcmiHqERoCoObg05MB4Pjp3nNBy1v7f2iYHQywsQ+wsi8s145EiIuGTu3 78Ld3Xg2QxY+RVDbZDsqZZHRQ1uvR5I= Received: by mail-lj1-f170.google.com with SMTP id 38308e7fff4ca-2af16426065so9834251fa.0 for ; Thu, 18 May 2023 07:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1684418748; x=1687010748; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=b7TdkTgtpE/I5dsPVP8TWDXytE/RrW+PwM2s8w+gwFY=; b=GS7wjn4PcfDHmmm7bCvTMJ6/VxFscD+K7r2sSRTWA92AzvdGAW+mLHSZ6LQgt3becE YCm/Gb1vZgOxcrPf0wjX2kToPXXJz9yKj6RJ0ONCwahGiZN279j/WDxfhzh7eSWWn8Cu LAabtXv4OEQ1iG8SuhAseIrvATG+9WGVS+JoP7UoRa0Di7NVc81cPV/Yc4Cnz96rTBoi j3uUmYaAGUvTcnPI55igt+XDtOZtuzZHbtYBTCd6MNDF/oG1cGxMZofUiqtBYjGcWjUX xotMhzyRhMsY2Wu5+aXROPe4A8D77YP2lOfomGxpZqjqvycqK4GGoDUm2ESKMtrpTsqG 58FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684418748; x=1687010748; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=b7TdkTgtpE/I5dsPVP8TWDXytE/RrW+PwM2s8w+gwFY=; b=kfZxW+ENFt6o/iiK+m/SV3oEWDS32bNRMFS2Eu60HIsyyYOWeiOAaHWbefC/k7GZHy o0h+mmAiyRl8V4gjrwSPqbfv86QUEMcocQRIW1H18WiZXdBixCk/U4Z5KYtOTOnf+pwM qDw2Qi0ZiNxzzOk6H5P7QTlMKS0qxikqixaykUGhrhq5/5GmgrzRgNOobuvcx3yfD3Yu qgd5MjJ0OnLxt3fZ9iilBnaFz+HNS3tsTrDLZT73fUpMsG3HLPPrpE77gyEzBTVsCVXB XeJBGEFBDok6cLK2RnU25kaPJbWaRqcRHCHlpqqcMY3+nwDw+kYukQ3XkowIyeuKfujI eXZQ== X-Gm-Message-State: AC+VfDwV7A7gId9RFr2+HZas8I8VN1xamcyYf7sImH45MGnfVkS/PEph 6rxrgsDOERsnVgKg9sXiSvaMG+v5MRdSQKVGTGM= X-Google-Smtp-Source: ACHHUZ6gAkeIlFb6/m30ztG2GkuG0Lv/Dt9j4d62CUz8C9sY+cA7/bnkyPTgGNRJcf5LpsMTOTseuRZu1v5Bqx9s4E0= X-Received: by 2002:a2e:3517:0:b0:2a7:a5f7:9651 with SMTP id z23-20020a2e3517000000b002a7a5f79651mr10655475ljz.23.1684418747549; Thu, 18 May 2023 07:05:47 -0700 (PDT) MIME-Version: 1.0 References: <20230518091431.299-1-ssawgyw@gmail.com> In-Reply-To: From: Yuwei Guan Date: Thu, 18 May 2023 22:05:11 +0800 Message-ID: Subject: Re: [PATCH v3] memblock: Add flags and nid info in memblock debugfs To: Anshuman Khandual Cc: rppt@kernel.org, akpm@linux-foundation.org, tsahu@linux.ibm.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 0CABA400EB X-Stat-Signature: kwpoman6spxmda7hstjhfahkm9pn4zgk X-HE-Tag: 1684418749-433861 X-HE-Meta: U2FsdGVkX1+kMwNJQ0LK8OWCT7vUpobpsNr8ZAmgu4VIQGqPafQGk2XYBNxauqYwDE3OvwhECec7sPWa11E7wgMrWuN9iOpl8D2KhrSVwAdph7YzGOtLPFIqI9avFQcvaQM5+TnjnpdM1A0yuWWywdcXNc0LBcoyMxR3lcz/w14qm/tbQ0tJ667kX13oBeKRcEqPS6ytWFLKW2/SXvzMQqlhbpKey0i+TjBvoj9jVM8Q/H0WAb1Dg/upfbIuFF7aUzjygP9fOepSL84GDiqB70OnlXzy9uk3ucSnvIymm1tFMg/Q7aPlOysiQ7IynsFNVlQKzTC5JTrziPHTkugGBqgoILCu828jP7p9mT6DYrrZXD1Eji+i8O4GYg1BWrXS+KgUYL3TLVxq/TE2ITYN73QIs/fneTGuAtZ8y8zPQOzXEv7dajy5+sJIq+flz/NumgLnGGxAEuX5NAPmQIlTfZ3hqT7QTADKyyelZdfyYMSEO8uuANR0S7HBX+s/WgH1HID0FpnIdoBlfMh2OT+Gv9ttj/JuGHvRKptJ9XqNV74fHtTR+Egwi8ksMb6cWJ2vSLLeSMxKz1XKIvaYIkS/o294KPPIwtUtg5+WlbxuZHxa+62bX4hhjlPE2W11zQ++rOOFPpJj7r9kWh8rU1fmHXtI0NZaD6WbAX19Ahsyks9ZtS9Gy1tDDSYERR1cWI0iz4E+dK0FLmjtkEM8OAN5Bh8obCO1ewRsQY5kBroT78TBha8+ZGsoRFcLS5ti3g5EesGYp1lZCM6VhBmuyhxP5fT0An0zpza63Gb3S+NMYCLDWJCvHLnExdKG6FKPnHtcxTHJvLIWOguri9B0L17yc2CT4rfZUAtof3uLRpRcJM3fHqHeo99DeG/yudUYEoJnUDerasuIxgmiC2pY7NTdYxJth8NLQzd0KmPLv0ORztN7C13TpI77JgNLxd2zrFsZ7jXUB7ZsBKUNgEAhy77 3ONufzqq X+q3eRQgf4gAqD5e3LBi0am3S0qwF/7c37MmNyopdTYIheh2CP0scSO8zihZU491KprGqJamdcaARl0pWTyue0GhG+gKZMyFbo9TGLGJ6ckEQgWFBRF//dygheVx4ppVv89bHD8LnRgkTMaPo4Np1EvY/LaZnklnLIV/kC0zYf8jChH0IVGCe/VRh0PV/A0F5uBhTtg01asIF4kDhE4cpQfnBq3mt6VBsfNUkdnA1WbqKP2jrLQqlmvVN4BX2GjtTbKOH+z/Sjd7+w7NotSdwK84w0DJ4k7PHbDyJA5T4GPK9NjLfeUR8qcUnPIGuQ58JJacRLzdPsXpoJiZupI6894BmzV2u2ayFeh/Mx7qnm8gjswhi0tcD3iFPNWsp9/qAo1C4o1v4OibV+Wka8IyQ7lCkzm2SSaZAyhbvFuQQKnGc9natdItmxSxdBw== 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: Anshuman Khandual =E4=BA=8E2023=E5=B9=B45=E6=9C= =8818=E6=97=A5=E5=91=A8=E5=9B=9B 18:12=E5=86=99=E9=81=93=EF=BC=9A > > > > On 5/18/23 14:44, Yuwei Guan wrote: > > Currently, the memblock debugfs can display the count of memblock_type = and > > the base and end of the reg. However, when memblock_mark_*() or > > memblock_set_node() is executed on some range, the information in the > > existing debugfs cannot make it clear why the address is not consecutiv= e. > > > > 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 > > 0: 0x0000000080000000..0x00000000901fffff NONE 0 > > 1: 0x0000000090200000..0x00000000905fffff NOMAP 0 > > 2: 0x0000000090600000..0x0000000092ffffff NONE 0 > > 3: 0x0000000093000000..0x00000000973fffff NOMAP 0 > > 4: 0x0000000097400000..0x00000000b71fffff NONE 0 > > 5: 0x00000000c0000000..0x00000000dfffffff NONE 0 > > 6: 0x00000000e2500000..0x00000000f87fffff NONE 0 > > 7: 0x00000000f8800000..0x00000000fa7fffff NOMAP 0 > > 8: 0x00000000fa800000..0x00000000fd3effff NONE 0 > > 9: 0x00000000fd3f0000..0x00000000fd3fefff NOMAP 0 > > 10: 0x00000000fd3ff000..0x00000000fd7fffff NONE 0 > > 11: 0x00000000fd800000..0x00000000fd901fff NOMAP 0 > > 12: 0x00000000fd902000..0x00000000fd909fff NONE 0 > > 13: 0x00000000fd90a000..0x00000000fd90bfff NOMAP 0 > > 14: 0x00000000fd90c000..0x00000000ffffffff NONE 0 > > 15: 0x0000000880000000..0x0000000affffffff NONE 0 > > Although, Mike had suggested to keep these flags print last, above > format looks good as well. > > > > > Signed-off-by: Yuwei Guan > > --- > > v3: > > - show string value for each memblock flag > > --- > > mm/memblock.c | 12 +++++++++++- > > 1 file changed, 11 insertions(+), 1 deletion(-) > > > > diff --git a/mm/memblock.c b/mm/memblock.c > > index 511d4783dcf1..5fba53f98b2d 100644 > > --- a/mm/memblock.c > > +++ b/mm/memblock.c > > @@ -2143,13 +2143,23 @@ static int memblock_debug_show(struct seq_file = *m, void *private) > > struct memblock_region *reg; > > int i; > > phys_addr_t end; > > + static const char flagname[BITS_PER_LONG][8] =3D { > > + [0 ... (BITS_PER_LONG-1)] =3D "?", > > Minor nit - > > Although checkpatch does not complain, should there be spaces between > the operator and operands e.g (BITS_PER_LONG - 1). > > > + > > + [ilog2(MEMBLOCK_HOTPLUG)] =3D "HOTPLUG", > > + [ilog2(MEMBLOCK_MIRROR)] =3D "MIRROR", > > + [ilog2(MEMBLOCK_NOMAP)] =3D "NOMAP", > > + [ilog2(MEMBLOCK_DRIVER_MANAGED)] =3D "DRV_MNG", > > + }; > > Also, BITS_PER_LONG sized array is really required here ? as there are > just four available memblock flags. > Hi Anshuman, The main reason to use BITS_PER_LONG is to reserve. If the flagname buffer is (ilog2(MEMBLOCK_DRIVER_MANAGED) + 1), memblock_flags adds a new attribute and does not add its name in debugfs, it will cause an overflow. But BITS_PER_LONG is too wasteful, so I implement a new solution. Please help to check it. struct memblock_type *type =3D m->private; struct memblock_region *reg; - int i; + int i, j; phys_addr_t end; + static const char *flagname[] =3D { + [ilog2(MEMBLOCK_HOTPLUG)] =3D "HOTPLUG", + [ilog2(MEMBLOCK_MIRROR)] =3D "MIRROR", + [ilog2(MEMBLOCK_NOMAP)] =3D "NOMAP", + [ilog2(MEMBLOCK_DRIVER_MANAGED)] =3D "DRV_MNG", + }; for (i =3D 0; i < type->cnt; i++) { reg =3D &type->regions[i]; end =3D reg->base + reg->size - 1; seq_printf(m, "%4d: ", i); - seq_printf(m, "%pa..%pa\n", ®->base, &end); + seq_printf(m, "%pa..%pa ", ®->base, &end); + seq_printf(m, "%4d ", memblock_get_region_node(reg)); + if (reg->flags) { + for (j =3D 0; j < ARRAY_SIZE(flagname); j++) { + if (reg->flags & (1U << j)) { + seq_printf(m, "%s\n", flagname[j]); + break; + } + } + if (j =3D=3D ARRAY_SIZE(flagname)) + seq_printf(m, "%s\n", "UNKNOWN"); + } else { + seq_printf(m, "%s\n", "NONE"); + } } > > > > for (i =3D 0; i < type->cnt; i++) { > > reg =3D &type->regions[i]; > > end =3D reg->base + reg->size - 1; > > > > seq_printf(m, "%4d: ", i); > > - seq_printf(m, "%pa..%pa\n", ®->base, &end); > > + seq_printf(m, "%pa..%pa ", ®->base, &end); > > + seq_printf(m, "%8s ", reg->flags ? flagname[ilog2(reg->fl= ags)] : "NONE"); > > + seq_printf(m, "%4d\n", memblock_get_region_node(reg)); > > } > > return 0; > > }