On Mon, 29 Jun 2009, Larry Finger wrote: > > I'd disagree with disabling slub debugging by default for caches where > > oo_order(s->min) increases as the result of using it. This particular > > page allocation failure is happening for, presumably, kmalloc-4096, and > > the system has 4K pages. Disabling debugging for that cache (and any of > > its aliases) implicitly will lead to errors going undiagnosed as a result. > > If the current behavior is not changed, I will be forced to disable > SLUB debugging, which will explicitly lead to errors that are > undiagnosed. You're buying debugging support at the cost of increased memory consumption when you enable CONFIG_SLUB_DEBUG_ON and that's causing the page allocation failures because of fragmentation. To reduce the minimum order required for caches such as kmalloc-4096, you'd have to disable debugging for that particular cache. It's my opinion that such a configuration should not be the default, however. You could argue adding `slub_debug=-,kmalloc-4096' support from the command line, but CONFIG_SLUB_DEBUG_ON should not change its well-defined purpose of enabling debugging on all slab caches. Otherwise the rest of us would be forced to add `slub_debug=,kmalloc-4096' for consistent behavior with older kernels. -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
