From: David Hildenbrand <david@redhat.com>
To: Minchan Kim <minchan@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm <linux-mm@kvack.org>,
LKML <linux-kernel@vger.kernel.org>,
John Dias <joaodias@google.com>, Michal Hocko <mhocko@suse.com>,
Jason Baron <jbaron@akamai.com>
Subject: Re: [PATCH v4] mm: page_alloc: dump migrate-failed pages
Date: Thu, 11 Mar 2021 19:53:01 +0100 [thread overview]
Message-ID: <c2bdb4c2-e025-53b2-5c96-6fe413eb242f@redhat.com> (raw)
In-Reply-To: <20210311183047.805891-1-minchan@kernel.org>
On 11.03.21 19:30, Minchan Kim wrote:
> Currently, debugging CMA allocation failures is quite limited.
> The most commong source of these failures seems to be page
s/commong/common/
> migration which doesn't provide any useful information on the
> reason of the failure by itself. alloc_contig_range can report
> those failures as it holds a list of migrate-failed pages.
>
> 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.
Maybe simply "The information logged by dump_page() has already proven
helpful for debugging allocation issues, like identifying long-term
pinnings on ZONE_MOVABLE or MIGRATE_CMA."
>
> The reason it approach with dynamic debug is the debug message
> could emit lots of noises as alloc_contig_range calls more
> frequently since it's a best effort allocator.
"Let's use the dynamic debugging infrastructure, such that we avoid
flooding the logs and creating a lot of noise on frequent
alloc_contig_range() calls. This information is helpful for debugging only."
>>>
>
> There are two ifdefery conditions to support common dyndbg options:
>
> - CONFIG_DYNAMIC_DEBUG_CORE && DYNAMIC_DEBUG_MODULE
> It aims for supporting the feature with only specific file
> with adding ccflags.
>
> - CONFIG_DYNAMIC_DEBUG
> It aims for supporting the feature with system wide globally.
>
> A simple example to enable the feature:
>
> Admin could enable the dump like this(by default, disabled)
>
> echo "func alloc_contig_dump_pages +p" > control
>
> Admin could disable it.
>
> echo "func alloc_contig_dump_pages =_" > control
>
> Detail goes Documentation/admin-guide/dynamic-debug-howto.rst
<<< I'd drop that completely and only mention:
"For details on dynamic debugging, see
Documentation/admin-guide/dynamic-debug-howto.rst."
As you have usage in the code itself, I think you don't have to be
repetitive. The ifdeffery seems to be common (e.g.,
include/linux/netdevice.) for dynamic debugging users, so I don't see
the need to describe that in detail.
>>>
>
> A concern is utility functions in dump_page uses inconsistent
> loglevels.
>
> __dump_page: KERN_WARNING
> __dump_page_owner: KERN_ALERT
> stack_trace_print: KERN_DEFAULT
>
> There are bunch of places to use the inconsistent loglevel
> utility functions(e.g., just grep dump_page/strace_trace_print).
> It's unfortunate but here we are. It could be addressed
> different patchset.
<<< I'd drop that completely and mention
"In the future, we might want to make the loglevels used inside
dump_page() consistent and eventually rework the way we log the
information here. See [1]"
Where [1] is a link to the discussion.
>
> Signed-off-by: Minchan Kim <minchan@kernel.org>
> ---
> * from v3 - https://lore.kernel.org/linux-mm/20210310180104.517886-1-minchan@kernel.org
> * add dyndgb usage comment - akpm
> * use dumpstack instead of warn_on - david
>
> * from v2 - https://lore.kernel.org/linux-mm/20210308202047.1903802-1-minchan@kernel.org/
> * remove ratelimit - mhocko
>
> * from v1 - https://lore.kernel.org/linux-mm/20210217163603.429062-1-minchan@kernel.org/
> * use dynamic debugging with system wide instead of per-call site - mhocko
>
> mm/page_alloc.c | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
Minor nits:
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 3e4b29ee2b1e..76fc202cb105 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -8453,6 +8453,36 @@ static unsigned long pfn_max_align_up(unsigned long pfn)
> pageblock_nr_pages));
> }
>
> +#if defined(CONFIG_DYNAMIC_DEBUG) || \
> + (defined(CONFIG_DYNAMIC_DEBUG_CORE) && defined(DYNAMIC_DEBUG_MODULE))
> +/*
> + * usage)
"usage)" looks wrong here. Did you mean "Usage:"
> + * dyndbg_dir="/sys/kernel/debug/dynamic_debug"
> + * To enable:
> + * echo "func alloc_contig_dump_pages +p" > $dyndbg_dir/control
> + * To disable:
> + * echo "func alloc_contig_dump_pages =_" > $dyndbg_dir/control
> + * For detail, read dynamic-debug-howto.rst
Maybe simply
"See admin-guide/dynamic-debug-howto.rst"
> + */
> +static void alloc_contig_dump_pages(struct list_head *page_list)
> +{
> + DEFINE_DYNAMIC_DEBUG_METADATA(descriptor,
> + "migrate failure");
You can fit that into a single line.
> +
> + if (DYNAMIC_DEBUG_BRANCH(descriptor)) {
> + struct page *page;
> +
> + dump_stack();
> + list_for_each_entry(page, page_list, lru)
> + dump_page(page, "migration failure");
> + }
> +}
> +#else
> +static inline void alloc_contig_dump_pages(struct list_head *page_list)
> +{
> +}
> +#endif
> +
> /* [start, end) must belong to a single zone. */
> static int __alloc_contig_migrate_range(struct compact_control *cc,
> unsigned long start, unsigned long end)
> @@ -8496,6 +8526,7 @@ static int __alloc_contig_migrate_range(struct compact_control *cc,
> NULL, (unsigned long)&mtc, cc->mode, MR_CONTIG_RANGE);
> }
> if (ret < 0) {
> + alloc_contig_dump_pages(&cc->migratepages);
> putback_movable_pages(&cc->migratepages);
> return ret;
> }
>
As I said, for my taste good enough for now. I would certainly preferred
what Michal suggested (e.g., doing it via debug loglevels), but this
gets the job done and is not too ugly.
Reviewed-by: David Hildenbrand <david@redhat.com>
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2021-03-11 18:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-11 18:30 [PATCH v4] mm: page_alloc: dump migrate-failed pages Minchan Kim
2021-03-11 18:53 ` David Hildenbrand [this message]
2021-03-11 19:27 ` Minchan Kim
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=c2bdb4c2-e025-53b2-5c96-6fe413eb242f@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=jbaron@akamai.com \
--cc=joaodias@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--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 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.