Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932395AbVLUMvR (ORCPT ); Wed, 21 Dec 2005 07:51:17 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932398AbVLUMvR (ORCPT ); Wed, 21 Dec 2005 07:51:17 -0500 Received: from ms-smtp-01.nyroc.rr.com ([24.24.2.55]:52682 "EHLO ms-smtp-01.nyroc.rr.com") by vger.kernel.org with ESMTP id S932395AbVLUMvQ (ORCPT ); Wed, 21 Dec 2005 07:51:16 -0500 Date: Wed, 21 Dec 2005 07:50:39 -0500 (EST) From: Steven Rostedt X-X-Sender: rostedt@gandalf.stny.rr.com To: Ingo Molnar cc: Christoph Lameter , Pekka Enberg , 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 In-Reply-To: <20051221063607.GA766@elte.hu> Message-ID: References: <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> <1135116715.13138.409.camel@localhost.localdomain> <20051221063607.GA766@elte.hu> 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: 2039 Lines: 45 On Wed, 21 Dec 2005, Ingo Molnar wrote: > > * Steven Rostedt wrote: > > > > > http://marc.theaimsgroup.com/?l=linux-kernel&m=113510997009883&w=2 > > > > > > Quite a long list of unsupported features. These academic papers > > > usually only focus on one thing. The SLAB allocator has to work > > > for a variety of situations though. > > > > > > It would help to explain what ultimately will be better in the new slab > > > allocator. The complexity could be taken care of by reorganizing the code. > > > > Honestly, what I would like is a simpler solution, whether we go with > > a new approach or reorganize the current slab. I need to get -rt > > working, and the code in slab is pulling my resources more than they > > can extend. I'm capable to convert slab today as it is for RT but it > > will probably take longer than I can afford. > > please, lets let the -rt tree out of the equation. The SLAB code is fine > on upstream, and it was a pure practical maintainance decision to go for > SLOB in the -rt tree. Yes, the SLAB code is complex, but i could hardly > list any complexity in it tht isnt justified with a performance > argument. _Maybe_ the SLAB code could be further cleaned up, maybe it > could even be replaced, but we'd have to see the patches first. In any > case, the -rt tree is not an argument that matters. You're right about the -rt tree not being an argument for upstream. I used it as an example of the complexities. This is not limited to -rt, but for any other changes as well. Years ago I tried changing the slab to run on a small embedded device with very little memory, and I was pretty much overwhelmed. Now I see that people are converting it for NUMA. I give them a lot of credit, since they must be smarter than I ;) -- Steve - 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/