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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no 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 5CCB3C433E0 for ; Tue, 9 Feb 2021 14:57:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id CE2D164EB8 for ; Tue, 9 Feb 2021 14:57:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CE2D164EB8 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E850A6B0005; Tue, 9 Feb 2021 09:57:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E5A276B006C; Tue, 9 Feb 2021 09:57:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D98646B006E; Tue, 9 Feb 2021 09:57:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0074.hostedemail.com [216.40.44.74]) by kanga.kvack.org (Postfix) with ESMTP id C3EA56B0005 for ; Tue, 9 Feb 2021 09:57:43 -0500 (EST) Received: from smtpin19.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 82918A8E6 for ; Tue, 9 Feb 2021 14:57:43 +0000 (UTC) X-FDA: 77799033606.19.patch77_0316e2f27608 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin19.hostedemail.com (Postfix) with ESMTP id 503B61ACC3A for ; Tue, 9 Feb 2021 14:57:43 +0000 (UTC) X-HE-Tag: patch77_0316e2f27608 X-Filterd-Recvd-Size: 3826 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Tue, 9 Feb 2021 14:57:42 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1612882661; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=NT5My67JE83c8tAQ8Vj7O5VdNPEkjvw0Ln0YAFM1sgc=; b=DmFSBCWKMuwLh62B0GyHFP86vFiEERQKvPAVLlLH7/QvzDqlqOq4BiRSAmY/Gb+F9QBW/y O2+gt58hpWIAHwj2BaiDlTSjPQm11giinGHuVnb2d198F333Kkt4qNYoZULj9hD60StZgd hxVCDOXOU5Xuz/koVQemOXEPW03Pj2U= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 9851BB201; Tue, 9 Feb 2021 14:57:41 +0000 (UTC) Date: Tue, 9 Feb 2021 15:57:38 +0100 From: Petr Mladek To: Andy Shevchenko Cc: Yafang Shao , willy@infradead.org, david@redhat.com, linmiaohe@huawei.com, vbabka@suse.cz, cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, rostedt@goodmis.org, sergey.senozhatsky@gmail.com, joe@perches.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 3/3] vsprintf: dump full information of page flags in pGp Message-ID: References: <20210209105613.42747-1-laoar.shao@gmail.com> <20210209105613.42747-4-laoar.shao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Tue 2021-02-09 16:16:01, Andy Shevchenko wrote: > On Tue, Feb 09, 2021 at 02:53:53PM +0100, Petr Mladek wrote: > > On Tue 2021-02-09 18:56:13, Yafang Shao wrote: > > ... > > > I am sorry for my ignorance. I am not familiar with MM. > > But it is pretty hard to understand what call does what. > > > > I have found the following comment in include/linux/page_flags.h: > > > > * The page flags field is split into two parts, the main flags area > > * which extends from the low bits upwards, and the fields area which > > * extends from the high bits downwards. > > > > Sigh, I know that you already reworked this several times because > > people "nitpicked" about the code style. But it seems that it > > rather diverged instead of converged. > > > > What about the following? > > Isn't is some like v1 or v2? Yes. And people suggested only some micro-optimizations and reported few small bugs there. But the code was heavily reworked in v3 to support the new %pGp[bl] variants. It also added the trick with the bitmap which invalidated all the previous suggestions. v3 and v4 review focused on behavior changes. We finally agreed on it. Let's give it more cycle and clean up the code after so many shuffles. > > Note: It is inpired by the names "main area" and "fields area" > > mentioned in the above comment from page_flags.h. > > I have later realized that "page_flags_layout" actually made > > sense as well. Feel free to rename page_flags_fileds > > back to page_flags_layout. > > > > Anyway, this is my proposal: > > What about to create a one format_flags() function which accepts new data > structure and do something like > > buf = format_flags(main_area); > buf = format_flags(fields_area); > return buf; I am not sure that it would make things easier. The handling of the main area is trivial and reuses existing structures. The handling of the fields area seems to be much more complicated. Best Regards, Petr