Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752974AbZLAAWN (ORCPT ); Mon, 30 Nov 2009 19:22:13 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752470AbZLAAWL (ORCPT ); Mon, 30 Nov 2009 19:22:11 -0500 Received: from waste.org ([173.11.57.241]:35374 "EHLO waste.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752359AbZLAAWK (ORCPT ); Mon, 30 Nov 2009 19:22:10 -0500 Subject: Re: lockdep complaints in slab allocator From: Matt Mackall To: David Rientjes Cc: Christoph Lameter , Pekka Enberg , Peter Zijlstra , "Paul E. McKenney" , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Nick Piggin In-Reply-To: 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> Content-Type: text/plain; charset="UTF-8" Date: Mon, 30 Nov 2009 18:21:15 -0600 Message-ID: <1259626875.29740.193.camel@calx> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3401 Lines: 68 On Mon, 2009-11-30 at 15:14 -0800, David Rientjes wrote: > On Fri, 27 Nov 2009, Christoph Lameter 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. > > > > Right, but the user is still left with a decision of which slab allocator > to compile into their kernel, each with distinct advantages and > disadvantages that get exploited for the wide range of workloads that it > runs. If slob could be merged into another allocator, it would be simple > to remove the distinction of it being seperate altogether, the differences > would depend on CONFIG_EMBEDDED instead. No no no wrong wrong wrong. Again, SLOB is the least mergeable of the set. It has vastly different priorities, design, and code from the rest. Literally the only thing it has in common with the other three is the interface. And it's not even something that -most- of embedded devices will want to use, so it can't be keyed off CONFIG_EMBEDDED anyway. If you've got even 16MB of memory, you probably want to use a SLAB-like allocator (ie not SLOB). But there are -millions- of devices being shipped that don't have that much memory, a situation that's likely to continue until you can fit a larger Linux system entirely in a <$1 microcontroller-sized device (probably 5 years off still). This thread is annoying. The problem that triggered this thread is not in SLOB/SLUB/SLQB, nor even in our bog-standard 10yo deep-maintenance known-to-work SLAB code. The problem was a FALSE POSITIVE from lockdep on code that PREDATES lockdep itself. There is nothing in this thread to indicate that there is a serious problem maintaining multiple allocators. In fact, considerably more time has been spent (as usual) debating non-existent problems than fixing real ones. I agree that having only one of SLAB/SLUB/SLQB would be nice, but it's going to take a lot of heavy lifting in the form of hacking and benchmarking to have confidence that there's a clear performance winner. Given the multiple dimensions of performance (scalability/throughput/latency for starters), I don't even think there's good a priori reason to believe that a clear winner CAN exist. SLUB may always have better latency, and SLQB may always have better throughput. If you're NYSE, you might have different performance priorities than if you're Google or CERN or Sony that amount to millions of dollars. Repeatedly saying "but we should have only one allocator" isn't going to change that. -- http://selenic.com : development and support for Mercurial and Linux -- 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/