Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760959AbYAJTZT (ORCPT ); Thu, 10 Jan 2008 14:25:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1761021AbYAJTYx (ORCPT ); Thu, 10 Jan 2008 14:24:53 -0500 Received: from waste.org ([66.93.16.53]:34327 "EHLO waste.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1761000AbYAJTYv (ORCPT ); Thu, 10 Jan 2008 14:24:51 -0500 Subject: Re: [RFC PATCH] greatly reduce SLOB external fragmentation From: Matt Mackall To: Christoph Lameter Cc: Linus Torvalds , Pekka J Enberg , Ingo Molnar , Hugh Dickins , Andi Kleen , Peter Zijlstra , Linux Kernel Mailing List In-Reply-To: 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> <1199641910.8215.28.camel@cinder.waste.org> <1199906151.6245.57.camel@cinder.waste.org> <1199919548.6245.74.camel@cinder.waste.org> <1199987366.5331.92.camel@cinder.waste.org> Content-Type: text/plain Date: Thu, 10 Jan 2008 13:23:52 -0600 Message-Id: <1199993032.5331.155.camel@cinder.waste.org> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2032 Lines: 48 On Thu, 2008-01-10 at 11:16 -0800, Christoph Lameter wrote: > On Thu, 10 Jan 2008, Matt Mackall wrote: > > > Here I'm going to differ with you. The premises of the SLAB concept > > (from the original paper) are: > > > > a) fragmentation of conventional allocators gets worse over time > > Even fragmentation of SLAB/SLUB gets worses over time. That is why we need > a defrag solution. > > > b) grouping objects of the same -type- (not size) together should mean > > they have similar lifetimes and thereby keep fragmentation low > > I agree that is crap. The lifetimes argument is mostly only exploitable in > benchmarks. That is why SLUB just groups them by size if possible. > > > d) constructors and destructors are cache-friendly > > I agree. Crap too. We removed the destructors. The constructors are needed > so that objects in slab pages always have a definite state. That is f.e. > necessary for slab defragmentation because it has to be able to inspect an > object at an arbitrary time and either remove it or move it to another > slab page. Are you saying that the state of -freed- objects matters for your active defragmentation? That's odd. > Constructors also make sense because the initialization of a cache object > may be expensive. Initializing list heads and spinlocks can take some code > and that code can be omitted if objects have a definite state when they > are free. We saw that when measuring the buffer_head constructors effect > on performance. Hmm. SLOB proves that you don't need to segregate objects based on constructors, so you could combine even slabs that have constructors and just delay construction until allocation. I'm surprised constructors have measurable advantage.. -- Mathematics is the supreme nostalgia of our time. -- 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/