From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "e4.ny.us.ibm.com", Issuer "Equifax" (verified OK)) by ozlabs.org (Postfix) with ESMTP id 592B167B22 for ; Fri, 20 Oct 2006 06:37:19 +1000 (EST) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.13.8/8.12.11) with ESMTP id k9JKbEpP024043 for ; Thu, 19 Oct 2006 16:37:14 -0400 Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k9JKbEFr273470 for ; Thu, 19 Oct 2006 16:37:14 -0400 Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k9JKbDJk005151 for ; Thu, 19 Oct 2006 16:37:13 -0400 Subject: Re: kernel BUG in __cache_alloc_node at linux-2.6.git/mm/slab.c:3177! From: Will Schmidt To: Christoph Lameter In-Reply-To: References: <1161026409.31903.15.camel@farscape> <1161031821.31903.28.camel@farscape> <17717.50596.248553.816155@cargo.ozlabs.ibm.com> <17718.39522.456361.987639@cargo.ozlabs.ibm.com> <17719.1849.245776.4501@cargo.ozlabs.ibm.com> <20061019163044.GB5819@krispykreme> Content-Type: text/plain Date: Thu, 19 Oct 2006 15:37:09 -0500 Message-Id: <1161290229.8946.51.camel@farscape> Mime-Version: 1.0 Cc: akpm@osdl.org, linuxppc-dev@ozlabs.org, Paul Mackerras , Anton Blanchard , linux-kernel@vger.kernel.org Reply-To: will_schmidt@vnet.ibm.com List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Thu, 2006-19-10 at 10:03 -0700, Christoph Lameter wrote: > I would expect this patch to fix your issues. This will allow fallback > allocations to occur in the page allocator during slab bootstrap. This > means your per node queues will be contaminated as they were before. After > the slab allocator is fully booted then the per node queues will become > gradually become node clean. > > I think it would be better if the PPC arch would fix this issue > by either making memory available on node 0 or setting up node 1 as > the boot node. > This didnt fix the problem on my box. I tried this both against mm and linux-2.6.git > Signed-off-by: Christoph Lameter > > Index: linux-2.6.19-rc2-mm1/mm/slab.c > =================================================================== > --- linux-2.6.19-rc2-mm1.orig/mm/slab.c 2006-10-19 11:54:24.000000000 -0500 > +++ linux-2.6.19-rc2-mm1/mm/slab.c 2006-10-19 11:59:24.208194796 -0500 > @@ -1589,7 +1589,10 @@ static void *kmem_getpages(struct kmem_c > * the needed fallback ourselves since we want to serve from our > * per node object lists first for other nodes. > */ > - flags |= cachep->gfpflags | GFP_THISNODE; > + if (g_cpucache_up != FULL) > + flags |= cachep->gfpflags; > + else > + flags |= cachep->gfpflags | GFP_THISNODE; > > page = alloc_pages_node(nodeid, flags, cachep->gfporder); > if (!page) > _______________________________________________ > Linuxppc-dev mailing list > Linuxppc-dev@ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-dev