Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751817AbXLIQAW (ORCPT ); Sun, 9 Dec 2007 11:00:22 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751149AbXLIQAI (ORCPT ); Sun, 9 Dec 2007 11:00:08 -0500 Received: from pentafluge.infradead.org ([213.146.154.40]:59637 "EHLO pentafluge.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751099AbXLIQAH (ORCPT ); Sun, 9 Dec 2007 11:00:07 -0500 Date: Sun, 9 Dec 2007 07:59:21 -0800 From: Arjan van de Ven To: "Pekka Enberg" Cc: "Ingo Molnar" , "Linus Torvalds" , "Andrew Morton" , "Matt Mackall" , "Rafael J. Wysocki" , LKML , "Christoph Lameter" Subject: Re: tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52, [2.6.24-rc4-git5: Reported regressions from 2.6.23] Message-ID: <20071209075921.4a0e1240@laptopd505.fenrus.org> In-Reply-To: <84144f020712090020o5bdeb54fqaa9e6578bd066f29@mail.gmail.com> References: <200712080340.49546.rjw@sisk.pl> <20071208093039.GA28054@elte.hu> <20071208163749.GI19691@waste.org> <20071208100950.a3547868.akpm@linux-foundation.org> <20071208195211.GA3727@elte.hu> <20071208202930.GA17934@elte.hu> <84144f020712090020o5bdeb54fqaa9e6578bd066f29@mail.gmail.com> Organization: Intel X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.1; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1082 Lines: 27 On Sun, 9 Dec 2007 10:20:19 +0200 "Pekka Enberg" wrote: \ > Now, while SLAB code is "pleasant and straightforward code" (thanks, > btw) for UMA, it's really hairy for NUMA plus the "alien caches" eat > tons of memory .. and they make slab slower on numa systems for database workloads (I'm sure they do fine for SGI's customers HPC load though)) >(which is why Christoph wrote SLUB in the first place, > the current code in SLAB is mostly unfixable due to its *queuing* > nature). To be honest, a SLAB without the alien stuff might be one of the best performers today .... ;) (on database loads.. where slub is quite a disaster as everyone knows) -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org -- 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/