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=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 43038C433E0 for ; Fri, 15 Jan 2021 10:17:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id DF37D235F9 for ; Fri, 15 Jan 2021 10:17:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DF37D235F9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5E9F68D0154; Fri, 15 Jan 2021 05:17:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 59A5B8D0023; Fri, 15 Jan 2021 05:17:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D7418D0154; Fri, 15 Jan 2021 05:17:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0053.hostedemail.com [216.40.44.53]) by kanga.kvack.org (Postfix) with ESMTP id 365548D0023 for ; Fri, 15 Jan 2021 05:17:51 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 00998181AF5C2 for ; Fri, 15 Jan 2021 10:17:51 +0000 (UTC) X-FDA: 77707608342.08.deer59_3d0a4302752e Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id D88421819E76B for ; Fri, 15 Jan 2021 10:17:50 +0000 (UTC) X-HE-Tag: deer59_3d0a4302752e X-Filterd-Recvd-Size: 5962 Received: from mail-io1-f48.google.com (mail-io1-f48.google.com [209.85.166.48]) by imf42.hostedemail.com (Postfix) with ESMTP for ; Fri, 15 Jan 2021 10:17:50 +0000 (UTC) Received: by mail-io1-f48.google.com with SMTP id o6so17041580iob.10 for ; Fri, 15 Jan 2021 02:17:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MZVdOHKn2XCvXFO+t12bKz8ARTHWfcKgqQnavIKedp8=; b=mPBtK33DlIVbSa13dRFy/E/aHkSYmYu4jaA/eaCwpLcoHcPL6ccGEw5dhDIKM8GSIp pCG/HR4WlbxPaAh37of+zJGM+v9Gme8kD89NYSDP6lfKWpaxsuyaEZvZirzkmQiUELZM g/a8D36PHNNKJOiurH1b5uQYUTgViuXz2dumuLJbgbX9CBEp0XQ69t/xgO4bIjMsDra+ 1miwwjQ8d5mx4UwhEFhnHif89pzcfyPd9F2WPNTAf8ALNkobSrw2BviSF37Ijvz33FoD 2tBQRTUWtAtaadcDDXhnkbw0b8RrOfJXblEyhizwK97cuI5/LXVNxKpRwPU9yZaUjBWf jc8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MZVdOHKn2XCvXFO+t12bKz8ARTHWfcKgqQnavIKedp8=; b=kb3zLB3QDTSbrzrwSTAk3o04KpV/gUkrELbFuWV5uh1Ofi1IBodvlCLcN4NR+WCUFl vV+blsEUMx2HvsTbZ9COpvwRX1/vcckLlaPxH0yhUUGBpbAf0a0DRtyPXHQDVgp4Iwmi +sqM+qY9wAjYa7PEBfwtlWHhjRo3wKGaDZVJn71U+wH7r6c+mha9a8R+Slzr3m9lL5Ov Am7jewe+sARNsZ40KwfXsrD0ll5EEmge9X+6UDyb8uoPC53k68RP0/Ai9bk7IGtTZZL3 /egnKB+QYUrpoxwAaRvH9LSk13RUk8w92b5YwQ4zxIquizBqsTHtvba8dIY0oKBAggfo jejA== X-Gm-Message-State: AOAM531GF8MrCxvEZl2A6G78KuaPRLsg9cacR4Nd2wXCtx/yP1j5ZpDD RnEq6FoS3J02yHAhvbcQUwbFaf637PShMUm7TBs= X-Google-Smtp-Source: ABdhPJxbWKanaYst54oZZf+IUOS8UAzY2MSLkE8elzHU5ySSfVTR63XmIz4Y38Ncs9FoBXWv/MA548C0wK5Ypbw4cOM= X-Received: by 2002:a05:6e02:2142:: with SMTP id d2mr10198455ilv.142.1610705869979; Fri, 15 Jan 2021 02:17:49 -0800 (PST) MIME-Version: 1.0 References: <20210115061349.67386-1-laoar.shao@gmail.com> <20210115061349.67386-3-laoar.shao@gmail.com> <1acfa7dd-3662-0a60-41e7-ae3ead8aeeb8@redhat.com> In-Reply-To: <1acfa7dd-3662-0a60-41e7-ae3ead8aeeb8@redhat.com> From: Yafang Shao Date: Fri, 15 Jan 2021 18:17:13 +0800 Message-ID: Subject: Re: [PATCH 2/2] mm: introduce PAGE_FLAGS() to make output of page flags better To: David Hildenbrand Cc: Christoph Lameter , penberg@kernel.org, David Rientjes , iamjoonsoo.kim@lge.com, Andrew Morton , Matthew Wilcox , Johannes Weiner , Michal Hocko , osalvador@suse.de, linmiaohe@huawei.com, steven.price@arm.com, Roman Gushchin , "Huang, Ying" , Linux MM Content-Type: text/plain; charset="UTF-8" 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 Fri, Jan 15, 2021 at 6:15 PM David Hildenbrand wrote: > > On 15.01.21 11:10, Yafang Shao wrote: > > On Fri, Jan 15, 2021 at 4:39 PM David Hildenbrand wrote: > >> > >> On 15.01.21 07:13, Yafang Shao wrote: > >>> There're totally __NR_PAGEFLAGS page flags, but the type of page->flags is > >>> unsigned long, that makes the value of page->flags a little misleading when > >>> it is printed to the user. We'd better print the real pages flags, instead > >>> of the whole 64bits including the random values in the useless high bits. > >> > >> No, these are *not* random values. They include the nid, zid, and > >> section_nr - which are helpful to have at hand when debugging, or > >> detecting that something might be messed up there. > >> > > > > Thanks for the explanation. I just noticed the page-flags layout in > > page-flags-layout.h. > > > >>> > >>> There're two choices to achieve that, one of which is clear the useless > >> > >> Again, not useless. > >> > >>> high bits when we initlize the page->flags, the other is don't print the > >>> high bits when it is showed to the user. The latter one is better because > >>> it is in the slow path and the performance won't be impacted. > >>> > >>> Before that change, the output is, > >>> [ 8846.517809] INFO: Slab 0x00000000f42a2c60 objects=33 used=3 fp=0x0000000060d32ca8 flags=0x17ffffc0010200(slab|head) > >>> > >>> After that change, the output is, > >>> [ 8843.757770] INFO: Slab 0x00000000f0e98335 objects=33 used=3 fp=0x00000000b643c7d8 flags=0x10200(slab|head) > >>> > >> > >> Nack to the current approach. If you're going to strip this information, > >> you should expose it differently. E.g., printing page_zonenum() or > >> page_to_nid(). But still, then we might lose valuable information of > >> bits stored in there that shouldn't have been set. > >> > > > > How about changing the implementation of pGp in printk() ? > > In the new implementation of pGp we can dump the full information of > > page->flags, rather than the flag's name only. > > > > For example, > > 0xXXXXXXXX(node n, nid n, ..., slab|head) > > > > That will make it easier to understand, as it is not easy to look into > > the detail of page-flags layout. > > Not completely opposed to this. Just keep in mind that the information > stored in the high bits differs per configuration. See > include/linux/page-flags-layout.h > > So to dump reliably, you would have to consider all different flavors, > looking at SECTIONS_WIDTH, NODES_WIDTH, ZONES_WIDTH, LAST_CPUPID_WIDTH, > KASAN_TAG_WIDTH > > Might be helpful for other users as well, like in mm/memory-failure.c > Thanks for the suggestion. I will think about it. -- Thanks Yafang