Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp260386pxf; Wed, 10 Mar 2021 05:57:00 -0800 (PST) X-Google-Smtp-Source: ABdhPJxtIt6NK9pppZ+sieZzG7KVpPT4xj624lKEUHlalChtsGH5LQOE6fzbnX6TbzOj2A0IN5lb X-Received: by 2002:a17:906:5902:: with SMTP id h2mr3749505ejq.416.1615384620181; Wed, 10 Mar 2021 05:57:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615384620; cv=none; d=google.com; s=arc-20160816; b=tKGRqESPlPK3WZQfvkQ2KKDiP/yzNU/sTUb2F3jKW0Y3ZugekbCkOI2VfLhf6qoFg6 nFaEq+hlPok14Dc/7Ou0QgiihlGGOlbFY9qMVFW5HA/sfxetWGB0Zq0GNQjwncjcpr+S iJkaKdy6egcPJ9mg7P89s7K5v7Np498q9nUGdHFU9s0ptnIJlne8bPQwjtClgifulizO SlPpEaxYVaBk1E2vgJiBf/MfjYxwiHBePph5AykRmYPR7LP8l1ALLNwdqnq8bNHuAWwz QPLnM2beTotsadATXAHTR918asZHmQuXyItAwM9Mkgf+JQ/EBJFruvPFs3UNmvoxIXoU yhJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Ynb5w72NY+rJnL7ZUNtb0DAziwv6ypIpu01j5U3oDF0=; b=ViftbElb8/CYZWS0dxybszi5mrsLixaXBstRo1WE24PUwDDVVWtk8LQjwVCwtgL0fp orhjIZEspKMT1AMpkzMWfl8QPxQFgUPewuQJiiI5O0CSct+c/+RFyiJORPb3cfze4lY/ KosBr5v8b8nIne/RPESt8QHePDgFMyaHcmdm//12bCRZglGv4gwGr/CQvHZPPEvFVfhc O4rDRnFLr8P7yex0X9lQgCM29mu4EaQANW+8EIYlVqdARebqs9rP3h3tIoE4wCauSMEu FjcUartINPCHodWt3pbg4F0oR4UWFz5c/GSL54oPRWULbCdUZwaTTSDgZZ3gyUGwb+3V +mzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=dtf9xoa8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id j20si11415774ejy.7.2021.03.10.05.56.37; Wed, 10 Mar 2021 05:57:00 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=dtf9xoa8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232313AbhCJNzK (ORCPT + 99 others); Wed, 10 Mar 2021 08:55:10 -0500 Received: from mx2.suse.de ([195.135.220.15]:55996 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231790AbhCJNy7 (ORCPT ); Wed, 10 Mar 2021 08:54:59 -0500 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=1615384498; 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=Ynb5w72NY+rJnL7ZUNtb0DAziwv6ypIpu01j5U3oDF0=; b=dtf9xoa8uw+8wPnmhFPI4ktZchNiqWASPNhgFUR1Ci6SA0fkRACyCFyk6Ct5InbOsphh6n Umh4jvgMUcVOyU9qJTE1HxlERdH1YllpJEmJ+NVGVgq0T0QMZSRIhOMbn3l0jL/KqhgDsk n2yeETOVKtHmQyZnOreOVwE5pMiZ9k4= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 69530AEE5; Wed, 10 Mar 2021 13:54:58 +0000 (UTC) Date: Wed, 10 Mar 2021 14:54:57 +0100 From: Michal Hocko To: Matthew Wilcox Cc: Minchan Kim , Andrew Morton , linux-mm , LKML , John Dias , David Hildenbrand , Jason Baron Subject: Re: [PATCH v2] mm: page_alloc: dump migrate-failed pages Message-ID: References: <20210308202047.1903802-1-minchan@kernel.org> <20210310132623.GO3479805@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210310132623.GO3479805@casper.infradead.org> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 10-03-21 13:26:23, Matthew Wilcox wrote: > On Tue, Mar 09, 2021 at 10:32:51AM +0100, Michal Hocko wrote: > > Apart from the above, do we have to warn for something that is a > > debugging aid? A similar concern wrt dump_page which uses pr_warn and > > page owner is using even pr_alert. > > Would it make sense to add a loglevel parameter both into __dump_page > > and dump_page_owner? > > No. What would make sense is turning __dump_page() inside-out. > Something like printk("%pP\n"); > > In lib/vsprintf.c, there's a big switch statement in the function > pointer() that handles printing things like IPv6 addresses, dentries, > and function symbols. > > Then we can do whatever we want around the new %pP, including choosing > the log level, adding additional information, choosing to dump the page > to a sysfs file, etc, etc. Hmm, __dump_page has grown quite some heavy lifting over time and I am not sure this is a good candidate to put into printk proper (e.g. is it safe/reasonable to call get_kernel_nofault from printk - aka arbitrary context)?. But you've got a point that such a printk format wouldn't need to be 1:1 with the existing __dump_page. There is quite a lot to infer from page count, map count, flags, page type already. Then a question would be what is an actual advantage of %pP over dump_page_info(loglvl, p). One I can see is that %pP would allow to dump the state into a string and so it would be more versatile but I am not aware of a usecase for that (maybe tracing?). -- Michal Hocko SUSE Labs