Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752048AbZK0R2n (ORCPT ); Fri, 27 Nov 2009 12:28:43 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751607AbZK0R2m (ORCPT ); Fri, 27 Nov 2009 12:28:42 -0500 Received: from nlpi157.sbcis.sbc.com ([207.115.36.171]:41866 "EHLO nlpi157.prodigy.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751422AbZK0R2m (ORCPT ); Fri, 27 Nov 2009 12:28:42 -0500 Date: Fri, 27 Nov 2009 11:28:22 -0600 (CST) From: Christoph Lameter X-X-Sender: cl@router.home To: David Rientjes cc: Matt Mackall , Pekka Enberg , Peter Zijlstra , "Paul E. McKenney" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Nick Piggin Subject: Re: lockdep complaints in slab allocator In-Reply-To: Message-ID: References: <84144f020911192249l6c7fa495t1a05294c8f5b6ac8@mail.gmail.com> <1258729748.4104.223.camel@laptop> <1259002800.5630.1.camel@penberg-laptop> <1259003425.17871.328.camel@calx> <4B0ADEF5.9040001@cs.helsinki.fi> <1259080406.4531.1645.camel@laptop> <20091124170032.GC6831@linux.vnet.ibm.com> <1259082756.17871.607.camel@calx> <1259086459.4531.1752.camel@laptop> <1259090615.17871.696.camel@calx> <84144f020911241307u14cd2cf0h614827137e42378e@mail.gmail.com> <1259103315.17871.895.camel@calx> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) 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: 971 Lines: 23 On Wed, 25 Nov 2009, David Rientjes wrote: > On Tue, 24 Nov 2009, Matt Mackall wrote: > > > I'm afraid I have only anecdotal reports from SLOB users, and embedded > > folks are notorious for lack of feedback, but I only need a few people > > to tell me they're shipping 100k units/mo to be confident that SLOB is > > in use in millions of devices. > > > > It's much more popular than I had expected; do you think it would be > possible to merge slob's core into another allocator or will it require > seperation forever? It would be possible to create a slab-common.c and isolate common handling of all allocators. SLUB and SLQB share quite a lot of code and SLAB could be cleaned up and made to fit into such a framework. -- 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/