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: Wed, 10 Mar 2021 07:59:34 -0800 [thread overview]
Message-ID: <YEjs5vxO/FRLUHhl@google.com> (raw)
In-Reply-To: <YEjD91BprqJMZUah@dhcp22.suse.cz>
On Wed, Mar 10, 2021 at 02:04:55PM +0100, Michal Hocko wrote:
< snip >
> > > Also are all those CONFIG_DYNAMIC_DEBUG* ifdefs necessary? Can we
> > > simply enable DYNAMIC_DEBUG for page_alloc as I've suggested above?
> >
> > They are different usecases.
> >
> > With DYNAMIC_DEBUG_MODULE with CONFIG_DYNAMIC_DEBUG_CORE,
> > it works for only specific compile flags as you suggested.
> > (CONFIG_DYNAMIC_DEBUG_CORE is requirement to work DYNAMIC_DEBUG_MODULE.
> >
> > With CONFIG_DYNAMIC_DEBUG, user could enable/disable every dynamic
> > debug places without needing DYNAMIC_DEBUG_MODULE flags for source
> > files.
> >
> > Both usecase makes sense to me.
>
> Well, this is more of a question for dynamic debugging maintainers. But
> it would be really great to reduce the ifdefery as much as possible.
I don't understand why this is something particular case which is okay
to lose either way to make dyndbg dynamic.
next prev parent reply other threads:[~2021-03-10 15:59 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 [this message]
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=YEjs5vxO/FRLUHhl@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.