Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754039AbYAVVe0 (ORCPT ); Tue, 22 Jan 2008 16:34:26 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751255AbYAVVeQ (ORCPT ); Tue, 22 Jan 2008 16:34:16 -0500 Received: from netops-testserver-3-out.sgi.com ([192.48.171.28]:46196 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751407AbYAVVeP (ORCPT ); Tue, 22 Jan 2008 16:34:15 -0500 Date: Tue, 22 Jan 2008 13:34:14 -0800 (PST) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Mel Gorman cc: Olaf Hering , Pekka Enberg , linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org, "Aneesh Kumar K.V" , hanth Aravamudan , KAMEZAWA Hiroyuki , lee.schermerhorn@hp.com, Linux MM , akpm@linux-foundation.org Subject: Re: crash in kmem_cache_init In-Reply-To: <20080122212654.GB15567@csn.ul.ie> Message-ID: References: <20080117181222.GA24411@aepfle.de> <20080117211511.GA25320@aepfle.de> <20080118213011.GC10491@csn.ul.ie> <20080118225713.GA31128@aepfle.de> <20080122195448.GA15567@csn.ul.ie> <20080122212654.GB15567@csn.ul.ie> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1928 Lines: 46 On Tue, 22 Jan 2008, Mel Gorman wrote: > > After you reverted the slab memoryless node patch there should be per node > > structures created for node 0 unless the node is marked offline. Is it? If > > so then you are booting a cpu that is associated with an offline node. > > > > I'll roll a patch that prints out the online states before startup and > see what it looks like. Ok. Great. > > > > Can you see a better solution than this? > > > > Well this means that bootstrap will work by introducing foreign objects > > into the per cpu queue (should only hold per cpu objects). They will > > later be consumed and then the queues will contain the right objects so > > the effect of the patch is minimal. > > > > By minimal, do you mean that you expect it to break in some other > respect later or minimal as in "this is bad but should not have no > adverse impact". Should not have any adverse impact after the objects from the cpu queue have been consumed. If the cache_reaper tries to shift objects back from the per cpu queue into slabs then BUG_ONs may be triggered. Make sure you run the tests with full debugging please. > Whatever this was a problem fixed in the past or not, it's broken again now > :( . It's possible that there is a __GFP_THISNODE that can be dropped early > at boot-time that would also fix this problem in a way that doesn't > affect runtime (like altering cache_grow in my patch does). The dropping of GFP_THISNODE has the same effect as your patch. Objects from another node get into the per cpu queue. And on free we assume that per cpu queue objects are from the local node. If debug is on then we check that with BUG_ONs. -- 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/