From: David Hildenbrand <david@redhat.com>
To: Charan Teja Reddy <charante@codeaurora.org>,
akpm@linux-foundation.org, mhocko@suse.com, linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm: memory_hotplug: put migration failure information under DEBUG_VM
Date: Mon, 23 Nov 2020 15:08:16 +0100 [thread overview]
Message-ID: <9e2b8ee5-62b5-4f38-207e-b68b615e304d@redhat.com> (raw)
In-Reply-To: <1606140196-6053-1-git-send-email-charante@codeaurora.org>
On 23.11.20 15:03, Charan Teja Reddy wrote:
> When the pages are failed to get isolate or migrate, the page owner
> information along with page info is dumped. If there are continuous
> failures in migration(say page is pinned) or isolation, the log buffer
> is simply getting flooded with the page owner information. As most of
> the times page info is sufficient to know the causes for failures of
> migration or isolation, place the page owner information under DEBUG_VM.
>
> Signed-off-by: Charan Teja Reddy <charante@codeaurora.org>
> ---
> mm/memory_hotplug.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 63b2e46..f48f30d 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1326,7 +1326,10 @@ do_migrate_range(unsigned long start_pfn, unsigned long end_pfn)
>
> } else {
> pr_warn("failed to isolate pfn %lx\n", pfn);
> - dump_page(page, "isolation failed");
> + __dump_page(page, "isolation failed");
> +#if defined(CONFIG_DEBUG_VM)
> + dump_page_owner(page);
> +#endif
> }
> put_page(page);
> }
> @@ -1357,7 +1360,10 @@ do_migrate_range(unsigned long start_pfn, unsigned long end_pfn)
> list_for_each_entry(page, &source, lru) {
> pr_warn("migrating pfn %lx failed ret:%d ",
> page_to_pfn(page), ret);
> - dump_page(page, "migration failure");
> + __dump_page(page, "migration failure");
> +#if defined(CONFIG_DEBUG_VM)
> + dump_page_owner(page);
> +#endif
> }
> putback_movable_pages(&source);
> }
>
It might also make sense to provide an explicit opt-in whether to
pr_warn/dump at all. Most user simply don't care, yet dmesg gets flooded.
Acked-by: David Hildenbrand <david@redhat.com>
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2020-11-23 14:08 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-23 14:03 [PATCH] mm: memory_hotplug: put migration failure information under DEBUG_VM Charan Teja Reddy
2020-11-23 14:08 ` David Hildenbrand [this message]
2020-11-23 14:13 ` Michal Hocko
2020-11-23 15:10 ` Charan Teja Kalla
2020-11-24 7:41 ` Michal Hocko
2020-11-25 10:48 ` Charan Teja Kalla
2020-11-26 9:18 ` Michal Hocko
2020-11-27 10:23 ` Charan Teja Kalla
2020-11-27 12:02 ` Michal Hocko
2020-11-24 13:39 ` Vlastimil Babka
2020-11-25 11:10 ` Charan Teja Kalla
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=9e2b8ee5-62b5-4f38-207e-b68b615e304d@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=charante@codeaurora.org \
--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 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).