From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4510196A.5090306@yahoo.com.au> Date: Wed, 20 Sep 2006 02:23:06 +1000 From: Nick Piggin MIME-Version: 1.0 Subject: Re: [PATCH] Get rid of zone_table V2 References: <20060918132818.603196e2.akpm@osdl.org> <20060918161528.9714c30c.akpm@osdl.org> <20060918165808.c410d1d4.akpm@osdl.org> <20060918173134.d3850903.akpm@osdl.org> <20060918233337.ef539a2b.akpm@osdl.org> <20060919083851.75b26075.akpm@osdl.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: Andrew Morton , linux-mm@kvack.org, Andy Whitcroft , Dave Hansen List-ID: Christoph Lameter wrote: > On Tue, 19 Sep 2006, Andrew Morton wrote: > > >>So it's not completely obvious what the best approach is here. It's an >>area of some delicacy which requires some thought and testing. > > > The primary thing that I though was worth doing is to get the size of > struct zone to a power of 2. Then the multiply is avoided in page_zone. > It just happened that this was possible by removing the > padding. > > Would be okay to grow the size of struct zone to the next power of 2 > bytes? I'd say yes: it is only memory we're talking about here, not cachelines, because the whole thing is cacheline aligned up the wazoo anyway. Let's see, on your example system that would take up an extra 896 bytes per struct zone... not too bad. And it is a better solution than shrinking because it will work on all architectures and configurations. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com -- 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