On Tue, 2 Feb 2016 23:37:50 +0100 Christian Borntraeger [off-list ref] wrote:

On 02/02/2016 11:21 PM, Andrew Morton wrote:

quoted

On Tue, 2 Feb 2016 22:53:36 +0100 Christian Borntraeger [off-list ref] wrote:

quoted

quoted

quoted

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?

https://lkml.org/lkml/2016/1/29/266 

That's already in linux-next so I can't apply it.

Well, I can, but it's a hassle.  What's happening here?

I pushed it on my tree for kbuild testing purposes some days ago. 
Will drop so that it can go via mm.

There are other patches that I haven't merged because they were already
in -next.  In fact I think I dropped them because they later popped up
in -next.

Some or all of:

lib-spinlock_debugc-prevent-an-infinite-recursive-cycle-in-spin_dump.patch
mm-provide-debug_pagealloc_enabled-without-config_debug_pagealloc.patch
x86-query-dynamic-debug_pagealloc-setting.patch
s390-query-dynamic-debug_pagealloc-setting.patch
mm-provide-debug_pagealloc_enabled-without-config_debug_pagealloc.patch
x86-query-dynamic-debug_pagealloc-setting.patch
s390-query-dynamic-debug_pagealloc-setting.patch

So please resend everything which you think is needed.