Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757439AbZCCQm6 (ORCPT ); Tue, 3 Mar 2009 11:42:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754700AbZCCQmt (ORCPT ); Tue, 3 Mar 2009 11:42:49 -0500 Received: from smtp3.ultrahosting.com ([74.213.175.254]:60794 "EHLO smtp.ultrahosting.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752463AbZCCQms (ORCPT ); Tue, 3 Mar 2009 11:42:48 -0500 Date: Tue, 3 Mar 2009 11:31:46 -0500 (EST) From: Christoph Lameter X-X-Sender: cl@qirst.com To: Mel Gorman cc: Lin Ming , Pekka Enberg , Linux Memory Management List , Rik van Riel , KOSAKI Motohiro , Johannes Weiner , Nick Piggin , Linux Kernel Mailing List , Zhang Yanmin , Peter Zijlstra , Ingo Molnar Subject: Re: [RFC PATCH 00/19] Cleanup and optimise the page allocator V2 In-Reply-To: <20090302112122.GC21145@csn.ul.ie> Message-ID: References: <1235477835-14500-1-git-send-email-mel@csn.ul.ie> <1235639427.11390.11.camel@minggr> <20090226110336.GC32756@csn.ul.ie> <1235647139.16552.34.camel@penberg-laptop> <20090226112232.GE32756@csn.ul.ie> <1235724283.11610.212.camel@minggr> <20090302112122.GC21145@csn.ul.ie> 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: 1321 Lines: 25 On Mon, 2 Mar 2009, Mel Gorman wrote: > Going by the vanilla kernel, a *large* amount of time is spent doing > high-order allocations. Over 25% of the cost of buffered_rmqueue() is in > the branch dealing with high-order allocations. Does UDP-U-4K mean that 8K > pages are required for the packets? That means high-order allocations and > high contention on the zone-list. That is bad obviously and has implications > for the SLUB-passthru patch because whether 8K allocations are handled by > SL*B or the page allocator has a big impact on locking. > > Next, a little over 50% of the cost get_page_from_freelist() is being spent > acquiring the zone spinlock. The implication is that the SL*B allocators > passing in order-1 allocations to the page allocator are currently going to > hit scalability problems in a big way. The solution may be to extend the > per-cpu allocator to handle magazines up to PAGE_ALLOC_COSTLY_ORDER. I'll > check it out. Then we are increasing the number of queues dramatically in the page allocator. More of a memory sink. Less cache hotness. -- 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/