Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760927AbYAJTYb (ORCPT ); Thu, 10 Jan 2008 14:24:31 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756710AbYAJTYP (ORCPT ); Thu, 10 Jan 2008 14:24:15 -0500 Received: from relay1.sgi.com ([192.48.171.29]:53170 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755495AbYAJTYN (ORCPT ); Thu, 10 Jan 2008 14:24:13 -0500 Date: Thu, 10 Jan 2008 11:24:12 -0800 (PST) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Matt Mackall cc: Linus Torvalds , Pekka J Enberg , Ingo Molnar , Hugh Dickins , Andi Kleen , Peter Zijlstra , Linux Kernel Mailing List Subject: Re: [RFC PATCH] greatly reduce SLOB external fragmentation In-Reply-To: <1199990565.5331.130.camel@cinder.waste.org> Message-ID: References: <84144f020801021109v78e06c6k10d26af0e330fc85@mail.gmail.com> <1199314218.4497.109.camel@cinder.waste.org> <20080103085239.GA10813@elte.hu> <1199378818.8274.25.camel@cinder.waste.org> <1199419890.4608.77.camel@cinder.waste.org> <1199641910.8215.28.camel@cinder.waste.org> <1199906151.6245.57.camel@cinder.waste.org> <1199919548.6245.74.camel@cinder.waste.org> <1199987366.5331.92.camel@cinder.waste.org> <1199990565.5331.130.camel@cinder.waste.org> 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: 1902 Lines: 32 On Thu, 10 Jan 2008, Matt Mackall wrote: > One idea I've been kicking around is pushing the boundary for the buddy > allocator back a bit (to 64k, say) and using SL*B under that. The page > allocators would call into buddy for larger than 64k (rare!) and SL*B > otherwise. This would let us greatly improve our handling of things like > task structs and skbs and possibly also things like 8k stacks and jumbo > frames. As SL*B would never be competing with the page allocator for > contiguous pages (the buddy allocator's granularity would be 64k), I > don't think this would exacerbate the page-level fragmentation issues. This would create another large page size (and that would have my enthusiastic support). It would decrease listlock effect drastically for SLUB. Even the initial simplistic implementation of SLUB was superior on the database transaction tests (I think it was up ~1%) on IA64 from the get go. Likely due to the larger 16k page size there. The larger page size could also be used for the page cache (ducking and running.....)? A 64k page size that could be allocated without zone locks would be very good for SLUB. However, isnt this is basically confessing that the page allocator is not efficient for 4k page allocations? I have seen some weaknesses there. The overhead in the allocation path in particular is bad and I was thinking about applying the same ideas used in SLUB also to the page allocator in order to bring the cycle count down from 500-1000 to 60 or so. Since both SLUB and SLOB use the page allocator for allocs >PAGE_SIZE this would not only benefit the general kernel but also the slab allocations. -- 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/