From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by kanga.kvack.org (Postfix) with ESMTP id 2E78F6B0071 for ; Wed, 7 May 2014 17:36:37 -0400 (EDT) Received: by mail-pa0-f47.google.com with SMTP id fa1so1694947pad.6 for ; Wed, 07 May 2014 14:36:36 -0700 (PDT) Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [2607:f8b0:400e:c02::235]) by mx.google.com with ESMTPS id db3si174561pbc.101.2014.05.07.14.36.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 May 2014 14:36:36 -0700 (PDT) Received: by mail-pd0-f181.google.com with SMTP id w10so1526189pde.26 for ; Wed, 07 May 2014 14:36:36 -0700 (PDT) Date: Wed, 7 May 2014 14:36:34 -0700 (PDT) From: David Rientjes Subject: Re: [patch] mm, slab: suppress out of memory warning unless debug is enabled In-Reply-To: <20140507142925.b0e31514d4cd8d5857b10850@linux-foundation.org> Message-ID: References: <20140507142925.b0e31514d4cd8d5857b10850@linux-foundation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton Cc: Pekka Enberg , Christoph Lameter , linux-kernel@vger.kernel.org, linux-mm@kvack.org 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. > > @@ -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? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org