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 C2DE46B01B0 for ; Tue, 25 May 2010 13:35:08 -0400 (EDT) Received: by fg-out-1718.google.com with SMTP id 16so303330fgg.8 for ; Tue, 25 May 2010 10:35:06 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20100525171959.GH20853@laptop> References: <20100525081634.GE5087@laptop> <20100525093410.GH5087@laptop> <20100525101924.GJ5087@laptop> <20100525154352.GB20853@laptop> <20100525171959.GH20853@laptop> Date: Tue, 25 May 2010 20:35:05 +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: Linus Torvalds , Christoph Lameter , Christoph Lameter , linux-mm@kvack.org, LKML , Andrew Morton , David Rientjes , Zhang Yanmin , Matthew Wilcox , Matt Mackall , Mel Gorman List-ID: On Tue, May 25, 2010 at 8:19 PM, Nick Piggin wrote: >> I'm not totally convinced but I guess we're about to find that out. >> How do you propose we benchmark SLAB while we clean it up > > Well the first pass will be code cleanups, bootstrap simplifications. > Then looking at what debugging features were implemented in SLUB but not > SLAB and what will be useful to bring over from there. Bootstrap might be easy to clean up but the biggest source of cruft comes from the deeply inlined, complex allocation paths. Cleaning those up is bound to cause performance regressions if you're not careful. -- 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