Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752864AbXEATZ4 (ORCPT ); Tue, 1 May 2007 15:25:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754523AbXEATZ4 (ORCPT ); Tue, 1 May 2007 15:25:56 -0400 Received: from netops-testserver-4-out.sgi.com ([192.48.171.29]:35760 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752864AbXEATZz (ORCPT ); Tue, 1 May 2007 15:25:55 -0400 Date: Tue, 1 May 2007 12:25:54 -0700 (PDT) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Hugh Dickins cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: 2.6.22 -mm merge plans: slub In-Reply-To: Message-ID: References: <20070430162007.ad46e153.akpm@linux-foundation.org> 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: 2561 Lines: 52 On Tue, 1 May 2007, Hugh Dickins wrote: > > Most of the rest of slub. Will merge it all. > > Merging slub already? I'm surprised. That's a very key piece of > infrastructure, and I doubt it's had the exposure it needs yet. Its not the default. Its just an alternative like SLOB. It will take some time to test with various loads in order to see if it can really replace SLAB in all scenarios. > Just what has it been widely tested on so far? x86_64. Not many > of us have ia64, but I guess SGI people will have been trying it > on that. Not i386, that's excluded. There is an i386 patch pending and I have used it on i386 for a while. > Not powerpc - hmm, I thought that was known, but looking I see no > ARCH_USES_SLAB_PAGE_STRUCT there: just built and tried to run it up, > crashes in slab_free from pgtable_free_tlb frpm free_pte_range from > free_pgd_range from free_pgtables from unmap_region form do_munmap. > That's 2.6.21-rc7-mm2. Hmmm... True I have not spend any time with that platform. We can set ARCH_USES_SLAB_PAGE_STRUCT there to switch it off. SLUB is the default for mm so I am a bit surprised that this did not surface earlier. > I've nothing against slub in itself, though I'm wary of its > cache merging (more scope for one corrupting another) (and Yes but then SLUB has more diagnostics etc etc than SLAB to prevent any issues. In debug mode all slabs are separate. The merge feature is very stable these days and significantly reduces cache overhead problems that plague SLAB and require it to have a complex object expiration technique. As a result I was able to rip out all timers. SLUB has no cache reaper nor any timer. Its silent if not in use. > sometimes I think Christoph spent one life uglifying slab for > NUMA, then another life ripping that all out to make slub ;) SLAB has a certain paradigm of doing things (queues) and I had to work within that framework. It was a group effort. SLUB is an answer to those complaints and a result of the lessons learned through years of some painful slab debugging. SLUB makes debugging extremely easy (and also the design is very simple and comprehensible). No rebuilding of the kernel. Just pop in a debug option on the command line which can even be targeted to a slab cache if we know that things break there. - 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/