linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Minchan Kim <minchan@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	John Dias <joaodias@google.com>,
	David Hildenbrand <david@redhat.com>,
	Jason Baron <jbaron@akamai.com>
Subject: Re: [PATCH v2] mm: page_alloc: dump migrate-failed pages
Date: Tue, 9 Mar 2021 10:32:51 +0100	[thread overview]
Message-ID: <YEdAw6gnp9XxoWUQ@dhcp22.suse.cz> (raw)
In-Reply-To: <20210308202047.1903802-1-minchan@kernel.org>

On Mon 08-03-21 12:20:47, Minchan Kim wrote:
> alloc_contig_range is usually used on cma area or movable zone.
> It's critical if the page migration fails on those areas so
> dump more debugging message.

I disagree with this statement. alloc_contig_range is not a reliable
allocator. Any user, be it CMA or direct users of alloc_contig_range
have to deal with allocation failures. Debugging information can be
still useful but considering migration failures critical is
overstatement to say the least.

> page refcount, mapcount with page flags on dump_page are
> helpful information to deduce the culprit. Furthermore,
> dump_page_owner was super helpful to find long term pinner
> who initiated the page allocation.
> 
> Admin could enable the dump like this(by default, disabled)
> 
> 	echo "func dump_migrate_failure_pages +p" > control
> 
> Admin could disable it.
> 
> 	echo "func dump_migrate_failure_pages =_" > control

My original idea was to add few pr_debug and -DDYNAMIC_DEBUG_MODULE for
page_alloc.c. It makes sense to enable a whole bunch at once though.
The naming should better reflect this is alloc_contig_rage related
because the above sounds like a generic migration failure thing.

Somebody more familiar with the dynamic debugging infrastructure needs
to have a look but from from a quick look it seems ok.

Do we really need all the ugly ifdefery, though? Don't we want to have
this compiled in all the time and just rely on the static branch managed
by the dynamic debugging framework?
 
[...]
> +void dump_migrate_failure_pages(struct list_head *page_list)
> +{
> +	DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,
> +			"migrate failure");
> +	if (DYNAMIC_DEBUG_BRANCH(descriptor) &&
> +			alloc_contig_ratelimit()) {
> +		struct page *page;
> +
> +		WARN(1, "failed callstack");
> +		list_for_each_entry(page, page_list, lru)
> +			dump_page(page, "migration failure");
> +	}

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?
-- 
Michal Hocko
SUSE Labs

  parent reply	other threads:[~2021-03-09  9:33 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-08 20:20 [PATCH v2] mm: page_alloc: dump migrate-failed pages Minchan Kim
2021-03-08 21:29 ` kernel test robot
2021-03-08 22:29   ` Minchan Kim
2021-03-09  0:41     ` [kbuild-all] " Rong Chen
2021-03-09  2:23       ` Minchan Kim
2021-03-09  0:21 ` Andrew Morton
2021-03-09  2:21   ` Minchan Kim
2021-03-09  0:30 ` kernel test robot
2021-03-09  0:30 ` [RFC PATCH] mm: page_alloc: alloc_contig_ratelimit() can be static kernel test robot
2021-03-09  9:32 ` Michal Hocko [this message]
2021-03-09 16:15   ` [PATCH v2] mm: page_alloc: dump migrate-failed pages Minchan Kim
2021-03-09 16:32     ` Michal Hocko
2021-03-09 17:27       ` Minchan Kim
2021-03-10 13:04         ` Michal Hocko
2021-03-10 15:59           ` Minchan Kim
2021-03-10  7:42     ` Minchan Kim
2021-03-10  8:20       ` David Hildenbrand
2021-03-10 15:45         ` Minchan Kim
2021-03-10 13:07       ` Michal Hocko
2021-03-10 16:05         ` Minchan Kim
2021-03-10 16:46           ` Michal Hocko
2021-03-10 17:06             ` Minchan Kim
2021-03-10 18:07               ` Minchan Kim
2021-03-10 13:26   ` Matthew Wilcox
2021-03-10 13:54     ` Michal Hocko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YEdAw6gnp9XxoWUQ@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=jbaron@akamai.com \
    --cc=joaodias@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=minchan@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).