From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751874Ab1GTOUX (ORCPT ); Wed, 20 Jul 2011 10:20:23 -0400 Received: from cantor2.suse.de ([195.135.220.15]:57089 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751418Ab1GTOUW (ORCPT ); Wed, 20 Jul 2011 10:20:22 -0400 Date: Wed, 20 Jul 2011 15:20:18 +0100 From: Mel Gorman To: Christoph Lameter Cc: Pekka Enberg , Konstantin Khlebnikov , Andrew Morton , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Matt Mackall Subject: Re: [PATCH] mm-slab: allocate kmem_cache with __GFP_REPEAT Message-ID: <20110720142018.GL5349@suse.de> References: <20110720121612.28888.38970.stgit@localhost6> <4E26D7EA.3000902@parallels.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 20, 2011 at 08:54:10AM -0500, Christoph Lameter wrote: > On Wed, 20 Jul 2011, Pekka Enberg wrote: > > > On Wed, 20 Jul 2011, Konstantin Khlebnikov wrote: > > > > 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. > > > > I'm still surprised you are seeing failures. mm/slab.c hasn't changed > > significantly in a long time. Why hasn't anyone reported this before? I'd > > still be inclined to shift the blame to the page allocator... Mel, Christoph? > > There was a lot of recent fiddling with the reclaim logic. Maybe some of > those changes caused the problem? > It's more likely that creating new slabs while under memory pressure significant enough to fail an order-4 allocation is a situation that is rarely tested. What kernel version did this failure occur on? What was the system doing at the time of failure? Can the page allocation failure message be posted? -- Mel Gorman SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail143.messagelabs.com (mail143.messagelabs.com [216.82.254.35]) by kanga.kvack.org (Postfix) with ESMTP id A35076B004A for ; Wed, 20 Jul 2011 10:20:24 -0400 (EDT) Date: Wed, 20 Jul 2011 15:20:18 +0100 From: Mel Gorman Subject: Re: [PATCH] mm-slab: allocate kmem_cache with __GFP_REPEAT Message-ID: <20110720142018.GL5349@suse.de> References: <20110720121612.28888.38970.stgit@localhost6> <4E26D7EA.3000902@parallels.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Christoph Lameter Cc: Pekka Enberg , Konstantin Khlebnikov , Andrew Morton , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Matt Mackall On Wed, Jul 20, 2011 at 08:54:10AM -0500, Christoph Lameter wrote: > On Wed, 20 Jul 2011, Pekka Enberg wrote: > > > On Wed, 20 Jul 2011, Konstantin Khlebnikov wrote: > > > > 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. > > > > I'm still surprised you are seeing failures. mm/slab.c hasn't changed > > significantly in a long time. Why hasn't anyone reported this before? I'd > > still be inclined to shift the blame to the page allocator... Mel, Christoph? > > There was a lot of recent fiddling with the reclaim logic. Maybe some of > those changes caused the problem? > It's more likely that creating new slabs while under memory pressure significant enough to fail an order-4 allocation is a situation that is rarely tested. What kernel version did this failure occur on? What was the system doing at the time of failure? Can the page allocation failure message be posted? -- Mel Gorman SUSE Labs -- 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