All of lore.kernel.org
 help / color / mirror / Atom feed
From: Minchan Kim <minchan@kernel.org>
To: Michal Hocko <mhocko@suse.com>
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 23:42:46 -0800	[thread overview]
Message-ID: <YEh4doXvyuRl5BDB@google.com> (raw)
In-Reply-To: <YEefLYiX6rF3Uk4E@google.com>

On Tue, Mar 09, 2021 at 08:15:41AM -0800, Minchan Kim wrote:

< snip >

> > [...]
> > > +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
> 
> Make sense.
> 
> > page owner is using even pr_alert.
> > Would it make sense to add a loglevel parameter both into __dump_page
> > and dump_page_owner?
> 
> Let me try it.

I looked though them and made first draft to clean them up.

It's bigger than my initial expectaion because there are many callsites
to use dump_page and stack_trace_print inconsistent loglevel. 
Since it's not a specific problem for this work, I'd like to deal with
it as separate patchset since I don't want to be stuck on here for my
initial goal.

FYI,

Subject: [RFC 0/5] make dump_page aware of loglevel

- Forked from [1]

dump_page uses __dump_page and dump_page_owner internally to
print various information. However, their printk loglevel are
inconsistent in that

__dump_page: KERN_WARNING
__dump_page_owner: KERN_ALERT
        stack_trace_print: KERN_DEFAULT

To make them consistent from dump_page, this patch introduces
pr_loglevel in printk and make the utility functions aware of
loglevel. Finally, last patch changes dump_page to support
loglevel to make the printing level consistent.

[1] https://lore.kernel.org/linux-mm/YEdAw6gnp9XxoWUQ@dhcp22.suse.cz/

Minchan Kim (5):
  mm: introduce pr_loglevel for __dump_[page]_owner
  stacktrace: stack_trace_print aware of loglevel
  mm: page_owner: dump_page_owner aware of loglevel
  mm: debug: __dump_page aware of loglevel
  mm: debug: dump_page aware of loglevel
  drivers/md/dm-bufio.c       |  2 +-
 drivers/virtio/virtio_mem.c |  2 +-
 fs/btrfs/ref-verify.c       |  2 +-
 fs/fuse/dev.c               |  2 +-
 include/linux/mmdebug.h     | 10 ++++++----
 include/linux/page_owner.h  |  8 ++++----
 include/linux/printk.h      | 12 +++++++++++
 include/linux/stacktrace.h  |  4 ++--
 kernel/backtracetest.c      |  2 +-
 kernel/dma/debug.c          |  3 ++-
 kernel/kcsan/report.c       |  7 ++++---
 kernel/locking/lockdep.c    |  3 ++-
 kernel/stacktrace.c         |  5 +++--
 mm/debug.c                  | 40 ++++++++++++++++++-------------------
 mm/filemap.c                |  2 +-
 mm/gup_test.c               |  4 ++--
 mm/huge_memory.c            |  4 ++--
 mm/kasan/report.c           |  4 ++--
 mm/kfence/report.c          |  3 ++-
 mm/kmemleak.c               |  2 +-
 mm/memory.c                 |  2 +-
 mm/memory_hotplug.c         |  4 ++--
 mm/page_alloc.c             |  4 ++--
 mm/page_isolation.c         |  2 +-
 mm/page_owner.c             | 24 +++++++++++-----------
 25 files changed, 88 insertions(+), 69 deletions(-)



  parent reply	other threads:[~2021-03-10  7:42 UTC|newest]

Thread overview: 31+ 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 21:29   ` kernel test robot
2021-03-08 22:29   ` Minchan Kim
2021-03-08 22:29     ` Minchan Kim
2021-03-09  0:41     ` Rong Chen
2021-03-09  0:41       ` [kbuild-all] " Rong Chen
2021-03-09  2:23       ` Minchan Kim
2021-03-09  2:23         ` [kbuild-all] " 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   ` 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  0:30   ` kernel test robot
2021-03-09  9:32 ` [PATCH v2] mm: page_alloc: dump migrate-failed pages Michal Hocko
2021-03-09 16:15   ` 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 [this message]
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=YEh4doXvyuRl5BDB@google.com \
    --to=minchan@kernel.org \
    --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=mhocko@suse.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.