Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754660AbXLUQpg (ORCPT ); Fri, 21 Dec 2007 11:45:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751314AbXLUQp3 (ORCPT ); Fri, 21 Dec 2007 11:45:29 -0500 Received: from smtp2.linux-foundation.org ([207.189.120.14]:33886 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751133AbXLUQp2 (ORCPT ); Fri, 21 Dec 2007 11:45:28 -0500 Date: Fri, 21 Dec 2007 08:44:42 -0800 (PST) From: Linus Torvalds To: Christoph Lameter cc: Ingo Molnar , Steven Rostedt , LKML , Andrew Morton , Peter Zijlstra , Christoph Hellwig , "Rafael J. Wysocki" Subject: Re: Major regression on hackbench with SLUB (more numbers) In-Reply-To: Message-ID: References: <1197049846.1645.68.camel@localhost.localdomain> <20071211143336.GA17866@elte.hu> <20071221120908.GA15926@elte.hu> 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: 2496 Lines: 68 On Fri, 21 Dec 2007, Christoph Lameter wrote: > > So we have 3 different regimes here (order 0): [ ... ] > The regression is contained because: [ ... ] Christoph, *NONE* of these arguments matter at all. The only thing that matters is the simple fact that real-life benchmarks show that SLUB is worse. It doesn't matter one whit that you can say that it's better under some circumstance that either isn't triggered, or when setting unrealistic and unusable parameters (ie big internal slab orders). > We could address this issue by: [...] > But given all the boundaries for the contention I would think that it is > not worth addressing. .. and this seems to be the single biggest reason to just say "revert SLUB entirely". If you aren't even motivated to fix the problems that have been reported, then SLUB isn't even a _potential_ solution, it's purely a problem, and since I am not IN THE LEAST interested in having three different allocators around, SLUB is going to get axed. In other words, here's the low-down: a) either SLUB can replace SLAB, or SLUB is going away This isn't open for discussion, Christoph. This was the rule back when it got merged in the first place. b) if SLUB performs worse than SLAB on real loads (TPC-C certainly being one, and while hackbench may be borderline, it's certainly less borderline than others), then SLUB cannot replace SLAB. See (a) c) If you aren't even interested in trying to fix it and are ignoring the reports, there is not even a _potential_ for SLUB for getting over these problems, and I should disable it and we should get over it as soon as possible, and this whole discussion is pretty much ended. See? It really is that simple. Either you say "Hell yes, I'll fix it", or SLUB goes away. There simply is no orther choice. When you say "not worth addressing", that to me is a clear an unambiguous "let's remove SLUB". The main reason for SLUB in the first place was SGI concerns. You seem to think that _only_ SGI concerns matter. Wrong. If SLUB remains a SGI-only thing and you don't fix it for other users, then SLUB gets reverted from the standard kernel. That's all. And it's not really worth discussing. 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/