Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757842AbYAEUSP (ORCPT ); Sat, 5 Jan 2008 15:18:15 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756558AbYAEUQ3 (ORCPT ); Sat, 5 Jan 2008 15:16:29 -0500 Received: from relay2.sgi.com ([192.48.171.30]:38990 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1757294AbYAEUQX (ORCPT ); Sat, 5 Jan 2008 15:16:23 -0500 Date: Sat, 5 Jan 2008 12:16:22 -0800 (PST) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Matt Mackall cc: Ingo Molnar , Linus Torvalds , Pekka Enberg , Hugh Dickins , Andi Kleen , Peter Zijlstra , Linux Kernel Mailing List Subject: Re: [PATCH] procfs: provide slub's /proc/slabinfo In-Reply-To: <1199485818.3821.46.camel@cinder.waste.org> Message-ID: References: <84144f020801021109v78e06c6k10d26af0e330fc85@mail.gmail.com> <1199314218.4497.109.camel@cinder.waste.org> <20080103085239.GA10813@elte.hu> <1199378818.8274.25.camel@cinder.waste.org> <1199419890.4608.77.camel@cinder.waste.org> <1199480150.3821.23.camel@cinder.waste.org> <1199485818.3821.46.camel@cinder.waste.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1841 Lines: 43 On Fri, 4 Jan 2008, Matt Mackall wrote: > > SLUB 32 (all memory of the 4k page is used for 128 byte objects) > > SLAB 29/30 (management structure occupies first two/three objects) > > SLOB 30(?) (Alignment results in object being 136 byte of effective size, > > we have 16 bytes leftover that could be used for a > > very small allocation. Right?) > > Don't know how you got to 136, the minimum alignment is 4 on x86. But I Right I am thinking about 64 bit systems where the alignment is 8 bytes. > already said in my last email that SLUB would win for the special case > of power of two allocations. But as long as we're looking at worst > cases, let's consider an alloc of 257 bytes.. Yup that hits it by forcing a rounding up to a size of 512 bytes because there is no intermediate cache size before 1024. The rounding up is a pretty weak spot in terms of memory use. > SLUB 8 (1016 bytes wasted) > SLOB 15 (105 bytes wasted, with 136 bytes still usable) Well we can actually turn this around. What I gave was not actually the worst case for SLOB. The worst case is an 8 byte allocation where SLOB needs double the memory of SLUB. SLUB 512 (Nothing wasted) SLOB 256 (Half of the page wasted for metadata) SLAB 119 (32 byte mininum alloc size + management struct needs) But these are all extreme cases. Depends on the mix of allocs who wins and from what I can tell the avoiding of rounding up to a power of two gives SLOB a key advantage. If we would find the worst offenders there and use kmem_cache_alloc instead then we may be able to offset that advantage. -- 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/