Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760244AbXLUWwB (ORCPT ); Fri, 21 Dec 2007 17:52:01 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753768AbXLUWvx (ORCPT ); Fri, 21 Dec 2007 17:51:53 -0500 Received: from smtp2.linux-foundation.org ([207.189.120.14]:53895 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756022AbXLUWvw (ORCPT ); Fri, 21 Dec 2007 17:51:52 -0500 Date: Fri, 21 Dec 2007 14:49:10 -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: 1900 Lines: 53 On Fri, 21 Dec 2007, Christoph Lameter wrote: > > It obviously can replace it and has replaced it for awhile now. No. If there are 6% performance regressions on TPC-C, then it CAN NOT replace it! > Well still SLUB is really superior to SLAB in many ways.... > > - SLUB is performance wise much faster than SLAB. No. Christoph, statements like this is *exactly* why I don't think SLUB can make it. You're closing your eyes to real performace *regression* reports, and then you claim thast SLUB is faster, because you find your own microbenchmarks that show so for specific loads. But those specific loads are apparetly never the issue. So stop saying that SLUB is "much faster", as long as hackbench shows that that is simply NOT THE CASE. It doesn't matter one whit if SLUB is lots faster, if it's faster for cases that never matter. So far, I don't think we've *ever* seen any actual benchmarks that involve any kind of real use where SLUB is really faster, and we have some major examples of SLUB being disastrously slower! Your special-case kmalloc performance tests don't matter, when real user programs show the exact opposite effect. And the fact that you dismiss those real user programs just because you have your own test harness is why I'm ready to throw in the towel on SLUB. I don't mind performance regressions, but I *do* mind performance regressions when the main author then says "look, a helicopter!" and points to some totally different thing and claims that the performance regression doesn't even exist! Because those kinds of performance regressions never get fixed, because they are ignored. 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/