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(-)
next prev 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.