On Wed, 7 May 2014 14:36:34 -0700 (PDT) David Rientjes <rientjes@xxxxxxxxxx> wrote: > On Wed, 7 May 2014, Andrew Morton wrote: > > > > When the slab or slub allocators cannot allocate additional slab pages, they > > > emit diagnostic information to the kernel log such as current number of slabs, > > > number of objects, active objects, etc. This is always coupled with a page > > > allocation failure warning since it is controlled by !__GFP_NOWARN. > > > > > > Suppress this out of memory warning if the allocator is configured without debug > > > supported. The page allocation failure warning will indicate it is a failed > > > slab allocation, so this is only useful to diagnose allocator bugs. > > > > > > Since CONFIG_SLUB_DEBUG is already enabled by default for the slub allocator, > > > there is no functional change with this patch. If debug is disabled, however, > > > the warnings are now suppressed. > > > > > > > I'm not seeing any reason for making this change. > > > > You think the spam in http://marc.info/?l=linux-kernel&m=139927773010514 > is meaningful? It also looks like two different errors when in reality it > is a single allocation. > > Unless you're debugging a slab issue, all the pertinent information is > already available in the page allocation failure warning emitted by the > page allocator: we already have the order and gfp mask. We also know it's > a slab allocation because of the __kmalloc in the call trace. > > Does this user care about that there are 207 slabs on node 0 with 207 > objects? Probably only if they are diagnosing a slab problem. I'd prefer something which can be added to the changelog to address this omission over a series of rhetorical questions. > > > @@ -1621,11 +1621,17 @@ __initcall(cpucache_init); > > > static noinline void > > > slab_out_of_memory(struct kmem_cache *cachep, gfp_t gfpflags, int nodeid) > > > { > > > +#if DEBUG > > > struct kmem_cache_node *n; > > > struct page *page; > > > unsigned long flags; > > > int node; > > > > > > + if (gfpflags & __GFP_NOWARN) > > > + return; > > > + if (!printk_ratelimit()) > > > + return; > > > > printk_ratelimit() is lame - it uses a single global state. So if > > random net driver is using printk_ratelimit(), that driver and slab > > will interfere with each other. > > > > Agreed, but it is a testiment to the uselessness of this information > already. The page allocation failure warnings are controlled by their own > ratelimiter, nopage_rs, but that's local to the page allocator. Do you > prefer that all these ratelimiters be moved to the global namespace for > generic use? As these messages are related then it probably makes sense for them to use a common ratelimit_state, hopefully local to slab.c. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>