Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932298AbVLUG5Q (ORCPT ); Wed, 21 Dec 2005 01:57:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932299AbVLUG5Q (ORCPT ); Wed, 21 Dec 2005 01:57:16 -0500 Received: from mx2.mail.elte.hu ([157.181.151.9]:62623 "EHLO mx2.mail.elte.hu") by vger.kernel.org with ESMTP id S932298AbVLUG5P (ORCPT ); Wed, 21 Dec 2005 01:57:15 -0500 Date: Wed, 21 Dec 2005 07:56:19 +0100 From: Ingo Molnar To: Steven Rostedt Cc: Pekka Enberg , Christoph Lameter , Alok N Kataria , Shobhit Dayal , Shai Fultheim , Matt Mackall , Andrew Morton , john stultz , Gunter Ohrner , linux-kernel@vger.kernel.org Subject: Re: [PATCH RT 00/02] SLOB optimizations Message-ID: <20051221065619.GC766@elte.hu> References: <1134860251.13138.193.camel@localhost.localdomain> <20051220133230.GC24408@elte.hu> <20051220135725.GA29392@elte.hu> <1135093460.13138.302.camel@localhost.localdomain> <20051220181921.GF3356@waste.org> <1135106124.13138.339.camel@localhost.localdomain> <84144f020512201215j5767aab2nc0a4115c4501e066@mail.gmail.com> <1135114971.13138.396.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1135114971.13138.396.camel@localhost.localdomain> User-Agent: Mutt/1.4.2.1i X-ELTE-SpamScore: -1.7 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-1.7 required=5.9 tests=ALL_TRUSTED,AWL autolearn=no SpamAssassin version=3.0.3 -2.8 ALL_TRUSTED Did not pass through any untrusted hosts 1.1 AWL AWL: From: address is in the auto white-list X-ELTE-VirusStatus: clean Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1301 Lines: 29 * Steven Rostedt wrote: > [...] Today's slab system is starting to become like the IDE where > nobody, but a select few sado-masochis, dare to venture in. (I've CC'd > them ;) [...] while it could possibly be cleaned up a bit, it's one of the best-optimized subsystems Linux has. Most of the "unnecessary complexity" in SLAB is related to a performance or a debugging feature. Many times i have looked at the SLAB code in a disassembler, right next to profile output from some hot workload, and have concluded: 'I couldnt do this any better even with hand-coded assembly'. SLAB-bashing has become somewhat fashionable, but i really challenge everyone to improve the SLAB code first (to make it more modular, easier to read, etc.), before suggesting replacements. the SLOB is nice because it gives us a simple option at the other end of the complexity spectrum. The SLOB should remain there. (but it certainly makes sense to make it faster, within certain limits, so i'm not opposing your SLOB patches per se.) Ingo - 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/