On Thu, 28 Jan 2016, David Rientjes wrote: > 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. > Ping? -- 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
