Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755446Ab1ELPQF (ORCPT ); Thu, 12 May 2011 11:16:05 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:52210 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752978Ab1ELPQD (ORCPT ); Thu, 12 May 2011 11:16:03 -0400 Subject: Re: [PATCH 3/3] mm: slub: Default slub_max_order to 0 From: James Bottomley To: Christoph Lameter Cc: Mel Gorman , Andrew Morton , Colin King , Raghavendra D Prabhu , Jan Kara , Chris Mason , Pekka Enberg , Rik van Riel , Johannes Weiner , linux-fsdevel , linux-mm , linux-kernel , linux-ext4 In-Reply-To: References: <1305127773-10570-1-git-send-email-mgorman@suse.de> <1305127773-10570-4-git-send-email-mgorman@suse.de> Content-Type: text/plain; charset="UTF-8" Date: Thu, 12 May 2011 10:15:59 -0500 Message-ID: <1305213359.2575.46.camel@mulgrave.site> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1707 Lines: 41 On Thu, 2011-05-12 at 09:43 -0500, Christoph Lameter wrote: > On Wed, 11 May 2011, Mel Gorman wrote: > > > --- a/mm/slub.c > > +++ b/mm/slub.c > > @@ -2198,7 +2198,7 @@ EXPORT_SYMBOL(kmem_cache_free); > > * take the list_lock. > > */ > > static int slub_min_order; > > -static int slub_max_order = PAGE_ALLOC_COSTLY_ORDER; > > +static int slub_max_order; > > If we really need to do this then do not push this down to zero please. > SLAB uses order 1 for the meax. Lets at least keep it theere. 1 is the current value. Reducing it to zero seems to fix the kswapd induced hangs. The problem does look to be some shrinker/allocator interference somewhere in vmscan.c, but the fact is that it's triggered by SLUB and not SLAB. I really think that what's happening is some type of feedback loops where one of the shrinkers is issuing a wakeup_kswapd() so kswapd never sleeps (and never relinquishes the CPU on non-preempt). > We have been using SLUB for a long time. Why is this issue arising now? > Due to compaction etc making reclaim less efficient? This is the snark argument (I've said it thrice the bellman cried and what I tell you three times is true). The fact is that no enterprise distribution at all uses SLUB. It's only recently that the desktop distributions started to ... the bugs are showing up under FC15 beta, which is the first fedora distribution to enable it. I'd say we're only just beginning widespread SLUB testing. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/