From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3]) by kanga.kvack.org (Postfix) with SMTP id EF9A46008F9 for ; Tue, 25 May 2010 06:45:09 -0400 (EDT) Received: by fxm11 with SMTP id 11so2646333fxm.14 for ; Tue, 25 May 2010 03:45:07 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20100525101924.GJ5087@laptop> References: <20100524070309.GU2516@laptop> <20100525020629.GA5087@laptop> <20100525070734.GC5087@laptop> <20100525081634.GE5087@laptop> <20100525093410.GH5087@laptop> <20100525101924.GJ5087@laptop> Date: Tue, 25 May 2010 13:45:07 +0300 Message-ID: Subject: Re: [RFC V2 SLEB 00/14] The Enhanced(hopefully) Slab Allocator From: Pekka Enberg Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org To: Nick Piggin Cc: Christoph Lameter , Christoph Lameter , linux-mm@kvack.org, LKML , Andrew Morton , Linus Torvalds , David Rientjes , Zhang Yanmin , Matthew Wilcox , Matt Mackall , Mel Gorman List-ID: Hi Nick, On Tue, May 25, 2010 at 1:19 PM, Nick Piggin wrote: >> Like I said, as a maintainer I'm happy to merge patches to modernize >> SLAB > > I think that would be most productive at this point. I will volunteer > to do it. OK, great! > As much as I would like to see SLQB be merged :) I think the best > option is to go with SLAB because it is very well tested and very > very well performing. I would have liked to see SLQB merged as well but it just didn't happen. > If Christoph or you or I or anyone have genuine improvements to make > to the core algorithms, then the best thing to do will just be do > make incremental changes to SLAB. I don't see the problem in improving SLUB even if we start modernizing SLAB. Do you? I'm obviously biased towards SLUB still for the reasons I already mentioned. I don't want to be a blocker for progress so if I turn out to be a problem, we should consider changing the maintainer(s). ;-) > There are several aspects to this. I think the first one will be to > actually modernize the code style, simplify the bootstrap process and > static memory allocations (SLQB goes even further than SLUB in this > regard), and to pull in debug features from SLUB. > > These steps should be made without any changes to core algorithms. > Alien caches can easily be disabled and at present they are really > only a problem for big Altixes where it is a known parameter to tune. > > From that point, I think we should concede that SLUB has not fulfilled > performance promises, and make SLAB the default. Sure. I don't care which allocator "wins" if we actually are able to get there. Pekka -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org