Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Received-SPF: Pass (protection.outlook.com: domain of nvidia.com designates
 216.228.112.34 as permitted sender) receiver=protection.outlook.com;
 client-ip=216.228.112.34; helo=mail.nvidia.com;
Subject: Re: [RFC PATCH] mm: dump_page: print total mapcount for compound page
To:     Yang Shi <shy828301@gmail.com>
CC:     Hugh Dickins <hughd@google.com>,
        Matthew Wilcox <willy@infradead.org>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Vlastimil Babka <vbabka@suse.cz>,
        Andrew Morton <akpm@linux-foundation.org>,
        Linux MM <linux-mm@kvack.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
References: <20210528175403.4506-1-shy828301@gmail.com>
 <ffc5612f-9403-9bc9-316f-fa50199769b2@nvidia.com>
 <CAHbLzkpMFq4955wOq9bANxtonm3cM+yFPh_gfr8nJmnXu9_fgg@mail.gmail.com>
From:   John Hubbard <jhubbard@nvidia.com>
Message-ID: <9d7cdf4f-502c-6710-1ff4-55c279f13039@nvidia.com>
Date:   Fri, 28 May 2021 12:59:33 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <CAHbLzkpMFq4955wOq9bANxtonm3cM+yFPh_gfr8nJmnXu9_fgg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 May 2021 19:59:34.4025
 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a1927aa7-a2f8-4126-bcc5-08d922131d92
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=43083d15-7273-40c1-b7db-39efd9ccc17a;Ip=[216.228.112.34];Helo=[mail.nvidia.com]
X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT057.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB3726
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 5/28/21 12:03 PM, Yang Shi wrote:
> On Fri, May 28, 2021 at 11:26 AM John Hubbard <jhubbard@nvidia.com> wrote:
>>
>> On 5/28/21 10:54 AM, Yang Shi wrote:
>>> The total mapcount is a useful information for debugging, but we can't
>>> call total_mapcount() directly since it calls some assertions which may
>>> be triggered as commit 6dc5ea16c86f ("mm,
>>> dump_page: do not crash with bad compound_mapcount()") met.
>>>
>>> We could implement yet another implementation for dump_page() but
>>> it has the limitation when individual mapcount of subpages is corrupted.
>>>
>>> Actually the total mapcount could be decoded from refcount, pincount and
>>> compound mapcount although it may be not very precise due to some
>>> transient references.
>>
>> If the mapcount calculation were in a separate routine, *and* if something
>> else in addition to dump_page() used it, then I'd be interested in
>> calling it from dump_page().
> 
> There is. The total_mapcount() is used by mm code. But as I mentioned
> in the commit log and that discussion email, it is not safe to call it
> directly in dump_page() path.
> 

Right! I apologize for missing the point that it is a separate function.

But unfortunately, the conclusion here is still the same, if you are
unable to actually call that function.

Basically, if you can make simple calls to retrieve and print out
information, then that's a good situation for diagnostics routines such
as dump_page(). But if you have to open-code calculations and those start
to get complex, then you have probably gone off in the wrong direction.

Keep in mind that the diag routines themselves have to be correct, and
they usually don't have the same level of testing that other routines
do.


thanks,
-- 
John Hubbard
NVIDIA