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. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
