From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail191.messagelabs.com (mail191.messagelabs.com [216.82.242.19]) by kanga.kvack.org (Postfix) with ESMTP id E80466B00CB for ; Mon, 23 Feb 2009 11:40:49 -0500 (EST) Date: Mon, 23 Feb 2009 16:40:47 +0000 From: Mel Gorman Subject: Re: [PATCH 04/20] Convert gfp_zone() to use a table of precalculated value Message-ID: <20090223164047.GO6740@csn.ul.ie> References: <1235344649-18265-1-git-send-email-mel@csn.ul.ie> <1235344649-18265-5-git-send-email-mel@csn.ul.ie> <200902240241.48575.nickpiggin@yahoo.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org To: Christoph Lameter Cc: Nick Piggin , Linux Memory Management List , Pekka Enberg , Rik van Riel , KOSAKI Motohiro , Johannes Weiner , Nick Piggin , Linux Kernel Mailing List , Lin Ming , Zhang Yanmin List-ID: On Mon, Feb 23, 2009 at 10:43:20AM -0500, Christoph Lameter wrote: > On Tue, 24 Feb 2009, Nick Piggin wrote: > > > > Are you sure that this is a benefit? Jumps are forward and pretty short > > > and the compiler is optimizing a branch away in the current code. > > > > Pretty easy to mispredict there, though, especially as you can tend > > to get allocations interleaved between kernel and movable (or simply > > if the branch predictor is cold there are a lot of branches on x86-64). > > > > I would be interested to know if there is a measured improvement. Not in kernbench at least, but that is no surprise. It's a small percentage of the overall cost. It'll appear in the noise for anything other than micro-benchmarks. > > It > > adds an extra dcache line to the footprint, but OTOH the instructions > > you quote is more than one icache line, and presumably Mel's code will > > be a lot shorter. > Yes, it's an index lookup of a shared read-only cache line versus a lot of code with branches to mispredict. I wasn't happy with the cache line consumption but it was the first obvious alternative. > Maybe we can come up with a version of gfp_zone that has no branches and > no lookup? > Ideally, yes, but I didn't spot any obvious way of figuring it out at compile time then or now. Suggestions? -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org