From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail138.messagelabs.com (mail138.messagelabs.com [216.82.249.35]) by kanga.kvack.org (Postfix) with SMTP id D1FBC6008F9 for ; Tue, 25 May 2010 06:47:32 -0400 (EDT) Received: by fxm11 with SMTP id 11so2648966fxm.14 for ; Tue, 25 May 2010 03:47:30 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20100521211452.659982351@quilx.com> <20100524070309.GU2516@laptop> <20100525020629.GA5087@laptop> <20100525070734.GC5087@laptop> Date: Tue, 25 May 2010 13:47:30 +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 Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org To: David Rientjes Cc: Nick Piggin , Christoph Lameter , Christoph Lameter , linux-mm@kvack.org, LKML , Andrew Morton , Linus Torvalds , Zhang Yanmin , Matthew Wilcox , Matt Mackall List-ID: Hi David, On Tue, May 25, 2010 at 1:02 PM, David Rientjes wrote= : >> I wouldn't say it's a nightmare, but yes, it could be better. From my >> point of view SLUB is the base of whatever the future will be because >> the code is much cleaner and simpler than SLAB. > > The code may be much cleaner and simpler than slab, but nobody (to date) > has addressed the significant netperf TCP_RR regression that slub has, fo= r > example. =A0I worked on a patchset to do that for a while but it wasn't > popular because it added some increments to the fastpath for tracking > data. Yes and IIRC I asked you to resend the series because while I care a lot about performance regressions, I simply don't have the time or the hardware to reproduce and fix the weird cases you're seeing. 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