Re: [PATCH v3 2/3] x86: query dynamic DEBUG_PAGEALLOC setting

David Rientjes
2016-01-28T23:03:45Z

On Thu, 28 Jan 2016, Christian Borntraeger wrote:

> Indeed, I only touched the identity mapping and dump stack.
> The question is do we really want to change free_init_pages as well?
> The unmapping during runtime causes significant overhead, but the
> unmapping after init imposes almost no runtime overhead. Of course,
> things get fishy now as what is enabled and what not.
>
> Kconfig after my patch "mm/debug_pagealloc: Ask users for default setting of debug_pagealloc"
> (in mm) now states
> ----snip----
> By default this option will have a small overhead, e.g. by not
> allowing the kernel mapping to be backed by large pages on some
> architectures. Even bigger overhead comes when the debugging is
> enabled by DEBUG_PAGEALLOC_ENABLE_DEFAULT or the debug_pagealloc
> command line parameter.
> ----snip----
>
> So I am tempted to NOT change free_init_pages, but the x86 maintainers
> can certainly decide differently. Ingo, Thomas, H. Peter, please advise.
>

I'm sorry, but I thought the discussion of the previous version of the
patchset led to deciding that all CONFIG_DEBUG_PAGEALLOC behavior would be
controlled by being enabled on the commandline and checked with
debug_pagealloc_enabled().

I don't think we should have a CONFIG_DEBUG_PAGEALLOC that does some stuff
and then a commandline parameter or CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT
to enable more stuff. It should either be all enabled by the commandline
(or config option) or split into a separate entity.
CONFIG_DEBUG_PAGEALLOC_LIGHT and CONFIG_DEBUG_PAGEALLOC would be fine, but
the current state is very confusing about what is being done and what
isn't.

It also wouldn't hurt to enumerate what is enabled and what isn't enabled
in the Kconfig entry.