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 X-Spam-Level: X-Spam-Status: No, score=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 266AEC433DB for ; Mon, 1 Feb 2021 13:05:40 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8260C64E06 for ; Mon, 1 Feb 2021 13:05:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8260C64E06 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=perches.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E777B6B0071; Mon, 1 Feb 2021 08:05:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E4D6F6B0073; Mon, 1 Feb 2021 08:05:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D15346B0074; Mon, 1 Feb 2021 08:05:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0134.hostedemail.com [216.40.44.134]) by kanga.kvack.org (Postfix) with ESMTP id BB16F6B0071 for ; Mon, 1 Feb 2021 08:05:38 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 07953180AD83B for ; Mon, 1 Feb 2021 13:05:38 +0000 (UTC) X-FDA: 77769720756.30.vest43_3e157bc275c2 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id 51A55180B3C8E for ; Mon, 1 Feb 2021 13:05:37 +0000 (UTC) X-HE-Tag: vest43_3e157bc275c2 X-Filterd-Recvd-Size: 4565 Received: from smtprelay.hostedemail.com (smtprelay0143.hostedemail.com [216.40.44.143]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Mon, 1 Feb 2021 13:05:36 +0000 (UTC) Received: from filter.hostedemail.com (clb03-v110.bra.tucows.net [216.40.38.60]) by smtprelay03.hostedemail.com (Postfix) with ESMTP id 561BF8384366; Mon, 1 Feb 2021 13:05:36 +0000 (UTC) X-Session-Marker: 6A6F6540706572636865732E636F6D X-HE-Tag: fly99_400121c275c2 X-Filterd-Recvd-Size: 3380 Received: from [192.168.1.159] (unknown [47.151.137.21]) (Authenticated sender: joe@perches.com) by omf17.hostedemail.com (Postfix) with ESMTPA; Mon, 1 Feb 2021 13:05:33 +0000 (UTC) Message-ID: <06481a01f551697d42c792506f3538d459ce8bdd.camel@perches.com> Subject: Re: [PATCH v2 3/3] vsprintf: dump full information of page flags in pGp From: Joe Perches To: Yafang Shao , andriy.shevchenko@linux.intel.com, david@redhat.com, vbabka@suse.cz, linmiaohe@huawei.com, cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, pmladek@suse.com, rostedt@goodmis.org, sergey.senozhatsky@gmail.com, linux@rasmusvillemoes.dk Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org Date: Mon, 01 Feb 2021 05:05:32 -0800 In-Reply-To: <20210201115610.87808-4-laoar.shao@gmail.com> References: <20210201115610.87808-1-laoar.shao@gmail.com> <20210201115610.87808-4-laoar.shao@gmail.com> Content-Type: text/plain; charset="ISO-8859-1" User-Agent: Evolution 3.38.1-1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit 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 Mon, 2021-02-01 at 19:56 +0800, Yafang Shao wrote: > Currently the pGp only shows the names of page flags, rather than > the full information including section, node, zone, last cpupid and > kasan tag. While it is not easy to parse these information manually > because there're so many flavors. Let's interpret them in pGp as well. > > - Before the patch, > [ 6343.396602] Slab 0x000000004382e02b objects=33 used=3 fp=0x000000009ae06ffc flags=0x17ffffc0010200(slab|head) > > - After the patch, > [ 6871.296131] Slab 0x00000000c0e19a37 objects=33 used=3 fp=0x00000000c4902159 flags=0x17ffffc0010200(Node 0,Zone 2,Lastcpupid 0x1fffff,slab|head) While debugfs is not an ABI, this format is exported in debugfs to userspace via mm/page_owner.c read_page_owner/print_page_owner. Does changing the output format matter to anyone? > diff --git a/lib/vsprintf.c b/lib/vsprintf.c [] > +static > +char *format_page_flags(char *buf, char *end, unsigned long page_flags) > +{ > + unsigned long flags = page_flags & ((1UL << NR_PAGEFLAGS) - 1); > + int size = ARRAY_SIZE(pfl); There's no real value in used-once variables. > + bool separator = false; > + int i; > + > + for (i = 0; i < size; i++) { Use ARRAY_SIZE here instead for (i = 0; i < ARRAY_SIZE(pfl); i++) { > + if (pfl[i].width == 0) > + continue; > + > + if (separator) { > + if (buf < end) > + *buf = ','; > + buf++; > + } > + > + > + buf = string(buf, end, pfl[i].name, *pfl[i].spec); > + > + buf = number(buf, end, (page_flags >> pfl[i].shift) & pfl[i].mask, > + *pfl[i].spec); > + separator = true; > + } Style question: Might this array be more intelligible with pointers instead of indexes? Something like: struct page_flags_layout *p; for (p = pfl; p < pfl + ARRAY_SIZE(pfl); p++) { if (p->width == 0) continue; if (p > pfl) { if (buf < end) *buf = ','; buf++; } buf = string(buf, end, p->name, *p->spec); buf = number(buf, end, (page_flags >> p->shift) & p->mask, *p->spec); } > + > + if (flags) { Maybe: if (page_flags & (BIT(NR_PAGEFLAGS) - 1)) { > + if (buf < end) > + *buf = ','; > + buf++; > + } > + > + return buf; > +} > +