From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 2 May 2007 11:53:03 -0700 (PDT) From: Christoph Lameter Subject: Re: 2.6.22 -mm merge plans: slub In-Reply-To: <20070502114233.30143b0b.akpm@linux-foundation.org> Message-ID: References: <20070430162007.ad46e153.akpm@linux-foundation.org> <20070501125559.9ab42896.akpm@linux-foundation.org> <20070502114233.30143b0b.akpm@linux-foundation.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Andrew Morton Cc: Hugh Dickins , linux-kernel@vger.kernel.org, linux-mm@kvack.org List-ID: On Wed, 2 May 2007, Andrew Morton wrote: > > This is a sensitive piece of the kernel as you say and we better allow the > > running of two allocator for some time to make sure that it behaves in all > > load situations. The design is fundamentally different so its performance > > characteristics may diverge significantly and perhaps there will be corner > > cases for each where they do the best job. > > eek. We'd need to fix those corner cases then. Our endgame > here really must be rm mm/slab.c. First we need to discover them and I doubt that mm covers much more than development loads. I hope we can get to a point where we have SLUB be the primarily allocator soon but I would expect various performance issues to show up. On the other hand: I am pretty sure that SLUB can replace SLOB completely given SLOBs limitations and SLUBs more efficient use of space. SLOB needs 8 bytes of overhead. SLUB needs none. We may just have to #ifdef out the debugging support to make the code be of similar size to SLOB too. SLOB is a general problem because its features are not compatible to SLAB. F.e. it does not support DESTROY_BY_RCU and does not do reclaim the right way etc etc. SLUB may turn out to be the ideal embedded slab allocator. -- 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