From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751737Ab1GTN2N (ORCPT ); Wed, 20 Jul 2011 09:28:13 -0400 Received: from relay.parallels.com ([195.214.232.42]:55325 "EHLO relay.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751006Ab1GTN2M (ORCPT ); Wed, 20 Jul 2011 09:28:12 -0400 Message-ID: <4E26D7EA.3000902@parallels.com> Date: Wed, 20 Jul 2011 17:28:10 +0400 From: Konstantin Khlebnikov User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.18) Gecko/20110416 SeaMonkey/2.0.13 MIME-Version: 1.0 To: Pekka Enberg CC: Andrew Morton , "linux-mm@kvack.org" , Christoph Lameter , "linux-kernel@vger.kernel.org" , Matt Mackall , "mgorman@suse.de" Subject: Re: [PATCH] mm-slab: allocate kmem_cache with __GFP_REPEAT References: <20110720121612.28888.38970.stgit@localhost6> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Pekka Enberg wrote: > On Wed, 20 Jul 2011, Konstantin Khlebnikov wrote: >> Order of sizeof(struct kmem_cache) can be bigger than PAGE_ALLOC_COSTLY_ORDER, >> thus there is a good chance of unsuccessful allocation. >> With __GFP_REPEAT buddy-allocator will reclaim/compact memory more aggressively. >> >> Signed-off-by: Konstantin Khlebnikov >> --- >> mm/slab.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/mm/slab.c b/mm/slab.c >> index d96e223..53bddc8 100644 >> --- a/mm/slab.c >> +++ b/mm/slab.c >> @@ -2304,7 +2304,7 @@ kmem_cache_create (const char *name, size_t size, size_t align, >> gfp = GFP_NOWAIT; >> >> /* Get cache's description obj. */ >> - cachep = kmem_cache_zalloc(&cache_cache, gfp); >> + cachep = kmem_cache_zalloc(&cache_cache, gfp | __GFP_REPEAT); >> if (!cachep) >> goto oops; > > The changelog isn't that convincing, really. This is kmem_cache_create() > so I'm surprised we'd ever get NULL here in practice. Does this fix some > problem you're seeing? If this is really an issue, I'd blame the page > allocator as GFP_KERNEL should just work. nf_conntrack creates separate slab-cache for each net-namespace, this patch of course not eliminates the chance of failure, but makes it more acceptable. struct kmem_size for slub is more compact, it uses pecpu-pointers instead of dumb NR_CPUS-size array. probably better to fix this side... > > Pekka From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail6.bemta7.messagelabs.com (mail6.bemta7.messagelabs.com [216.82.255.55]) by kanga.kvack.org (Postfix) with ESMTP id 5F5E96B004A for ; Wed, 20 Jul 2011 09:28:22 -0400 (EDT) Message-ID: <4E26D7EA.3000902@parallels.com> Date: Wed, 20 Jul 2011 17:28:10 +0400 From: Konstantin Khlebnikov MIME-Version: 1.0 Subject: Re: [PATCH] mm-slab: allocate kmem_cache with __GFP_REPEAT References: <20110720121612.28888.38970.stgit@localhost6> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Pekka Enberg Cc: Andrew Morton , "linux-mm@kvack.org" , Christoph Lameter , "linux-kernel@vger.kernel.org" , Matt Mackall , "mgorman@suse.de" Pekka Enberg wrote: > On Wed, 20 Jul 2011, Konstantin Khlebnikov wrote: >> Order of sizeof(struct kmem_cache) can be bigger than PAGE_ALLOC_COSTLY_ORDER, >> thus there is a good chance of unsuccessful allocation. >> With __GFP_REPEAT buddy-allocator will reclaim/compact memory more aggressively. >> >> Signed-off-by: Konstantin Khlebnikov >> --- >> mm/slab.c | 2 +- >> 1 files changed, 1 insertions(+), 1 deletions(-) >> >> diff --git a/mm/slab.c b/mm/slab.c >> index d96e223..53bddc8 100644 >> --- a/mm/slab.c >> +++ b/mm/slab.c >> @@ -2304,7 +2304,7 @@ kmem_cache_create (const char *name, size_t size, size_t align, >> gfp = GFP_NOWAIT; >> >> /* Get cache's description obj. */ >> - cachep = kmem_cache_zalloc(&cache_cache, gfp); >> + cachep = kmem_cache_zalloc(&cache_cache, gfp | __GFP_REPEAT); >> if (!cachep) >> goto oops; > > The changelog isn't that convincing, really. This is kmem_cache_create() > so I'm surprised we'd ever get NULL here in practice. Does this fix some > problem you're seeing? If this is really an issue, I'd blame the page > allocator as GFP_KERNEL should just work. nf_conntrack creates separate slab-cache for each net-namespace, this patch of course not eliminates the chance of failure, but makes it more acceptable. struct kmem_size for slub is more compact, it uses pecpu-pointers instead of dumb NR_CPUS-size array. probably better to fix this side... > > Pekka -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org