Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751709AbXBVQyX (ORCPT ); Thu, 22 Feb 2007 11:54:23 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751711AbXBVQyX (ORCPT ); Thu, 22 Feb 2007 11:54:23 -0500 Received: from cantor2.suse.de ([195.135.220.15]:59233 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751706AbXBVQyX (ORCPT ); Thu, 22 Feb 2007 11:54:23 -0500 To: Christoph Lameter Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: SLUB: The unqueued Slab allocator References: From: Andi Kleen Date: 22 Feb 2007 18:54:06 +0100 In-Reply-To: Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 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: 1103 Lines: 26 Christoph Lameter writes: > This is a new slab allocator which was motivated by the complexity of the > with the existing implementation. Thanks for doing that work. It certainly was long overdue. > D. SLAB has a complex cache reaper > > SLUB does not need a cache reaper for UP systems. This means constructors/destructors are becomming worthless? Can you describe your rationale why you think they don't make sense on UP? > G. Slab merging > > We often have slab caches with similar parameters. SLUB detects those > on bootup and merges them into the corresponding general caches. This > leads to more effective memory use. Did you do any tests on what that does to long term memory fragmentation? It is against the "object of same type have similar livetime and should be clustered together" theory at least. -Andi - 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/