Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263260AbTKYWvy (ORCPT ); Tue, 25 Nov 2003 17:51:54 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263298AbTKYWvy (ORCPT ); Tue, 25 Nov 2003 17:51:54 -0500 Received: from fw.osdl.org ([65.172.181.6]:12441 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S263260AbTKYWvx (ORCPT ); Tue, 25 Nov 2003 17:51:53 -0500 Date: Tue, 25 Nov 2003 14:51:42 -0800 (PST) From: Linus Torvalds To: pinotj@club-internet.fr cc: manfred@colorfullife.com, akpm@osdl.org, linux-kernel@vger.kernel.org Subject: Re: Re: [Oops] i386 mm/slab.c (cache_flusharray) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1010 Lines: 23 On Tue, 25 Nov 2003 pinotj@club-internet.fr wrote: > > 3. 2.6.0-test10 vanilla + PREEMPT_CONFIG=y + patch printk + patch magic numbers > The patch solves the problem, I can compile 4 times a kernel and do heavy work in parallele (load average around 1.2 during 2 hours) without any problems. Those magic numbers don't make any sense. In particular, SLAB_LIMIT is clearly bogus both in the original version and in the "magic number patch". The only place that uses SLAB_LIMIT is the code that decides how many entries fit in one slab, and quite frankly, it makes no _sense_ to have a SLAB_LIMIT that is big enough to be unsigned. "SLAB_LIMIT" should be something in the few hundreds, maybe. Manfred? What is the logic behind those nonsensical numbers? Linus - 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/