Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760900AbYAJTbT (ORCPT ); Thu, 10 Jan 2008 14:31:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753487AbYAJTbL (ORCPT ); Thu, 10 Jan 2008 14:31:11 -0500 Received: from netops-testserver-3-out.sgi.com ([192.48.171.28]:36006 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751741AbYAJTbJ (ORCPT ); Thu, 10 Jan 2008 14:31:09 -0500 Date: Thu, 10 Jan 2008 11:31:07 -0800 (PST) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Matt Mackall cc: Linus Torvalds , Pekka J Enberg , Ingo Molnar , Hugh Dickins , Andi Kleen , Peter Zijlstra , Linux Kernel Mailing List Subject: Re: [RFC PATCH] greatly reduce SLOB external fragmentation In-Reply-To: <1199993032.5331.155.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> <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> <1199993032.5331.155.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: 2023 Lines: 40 On Thu, 10 Jan 2008, Matt Mackall wrote: > > 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. The state of the object immediately after it is allocated matters for a defrag solution. A kmalloc leads to an object in a undetermined state if you have no constructor. Code will then initialize the object but defrag f.e. must be able to inspect the object before. This means either that the freed object has a defined state or that kmalloc establishes that state before the object is marked as allocated. > > 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.. That is not working if you need to inspect allocated objects at any time for a defrag solution. All objects in a defragmentable slab need to have a consistent object state if allocated. If you have some without constructors then these object have no defined state and may contain arbitrary bytes. -- 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/