Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751214AbWHPPHG (ORCPT ); Wed, 16 Aug 2006 11:07:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751215AbWHPPHG (ORCPT ); Wed, 16 Aug 2006 11:07:06 -0400 Received: from omx1-ext.sgi.com ([192.48.179.11]:6309 "EHLO omx1.americas.sgi.com") by vger.kernel.org with ESMTP id S1751214AbWHPPHE (ORCPT ); Wed, 16 Aug 2006 11:07:04 -0400 Date: Wed, 16 Aug 2006 08:06:50 -0700 (PDT) From: Christoph Lameter To: David Chinner cc: mpm@selenic.com, Marcelo Tosatti , linux-kernel@vger.kernel.org, Nick Piggin , Andi Kleen , Manfred Spraul Subject: Re: [MODSLAB 0/7] A modular slab allocator V1 In-Reply-To: <20060816081208.GL51703024@melbourne.sgi.com> Message-ID: References: <20060816022238.13379.24081.sendpatchset@schroedinger.engr.sgi.com> <20060816081208.GL51703024@melbourne.sgi.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 650 Lines: 15 On Wed, 16 Aug 2006, David Chinner wrote: > Also, some slab users probably want their own pool of objects that > nobody else can use - mempools are a good example of this - so there > needs to a way of indicating slabs should not be merged into the > kmalloc array. slabs are only merged if they are compatible with the kmalloc array. If a slab uses a memory pool then that would prohibit the merging. - 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/