Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753742AbZAZRhw (ORCPT ); Mon, 26 Jan 2009 12:37:52 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751824AbZAZRho (ORCPT ); Mon, 26 Jan 2009 12:37:44 -0500 Received: from smtp.ultrahosting.com ([74.213.174.254]:60336 "EHLO smtp.ultrahosting.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751656AbZAZRho (ORCPT ); Mon, 26 Jan 2009 12:37:44 -0500 Date: Mon, 26 Jan 2009 12:34:21 -0500 (EST) From: Christoph Lameter X-X-Sender: cl@qirst.com To: Nick Piggin cc: Pekka Enberg , "Zhang, Yanmin" , Lin Ming , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Linus Torvalds Subject: Re: [patch] SLQB slab allocator In-Reply-To: <20090123161017.GC14517@wotan.suse.de> Message-ID: References: <20090114150900.GC25401@wotan.suse.de> <20090115060330.GB17810@wotan.suse.de> <20090116031940.GL17810@wotan.suse.de> <20090119054730.GA22584@wotan.suse.de> <20090123041756.GH20098@wotan.suse.de> <20090123161017.GC14517@wotan.suse.de> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) 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: 1782 Lines: 40 On Fri, 23 Jan 2009, Nick Piggin wrote: > > SLUB can directly free an object to any slab page. "Queuing" on free via > > the per cpu slab is only possible if the object came from that per cpu > > slab. This is typically only the case for objects that were recently > > allocated. > > Ah yes ok that's right. But then you don't get LIFO allocation > behaviour for those cases. But you get more TLB local allocations. > > > hot objects when you switch to different "fast" pages. I don't consider > > > this to be "queueing done right". > > > > Yes you can loose track of caching hot objects. That is one of the > > concerns with the SLUB approach. On the other hand: Caching architectures > > get more and more complex these days (especially in a NUMA system). The > > Because it is more important to get good cache behaviour. Its going to be quite difficult to realize algorithm that guestimate what information the processor keeps in its caches. The situation is quite complex in NUMA systems. > So I think it is wrong to say it requires more metadata handling. SLUB > will have to switch pages more often or free objects to pages other than > the "fast" page (what do you call it?), so quite often I think you'll > find SLUB has just as much if not more metadata handling. Its the per cpu slab. SLUB does not switch pages often but frees objects not from the per cpu slab directly with minimal overhead compared to a per cpu slab free. The overhead is much less than the SLAB slowpath which has to be taken for alien caches etc. -- 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/