From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 19 Sep 2006 08:38:51 -0700 From: Andrew Morton Subject: Re: [PATCH] Get rid of zone_table V2 Message-Id: <20060919083851.75b26075.akpm@osdl.org> In-Reply-To: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: linux-mm@kvack.org, Andy Whitcroft , Dave Hansen List-ID: On Tue, 19 Sep 2006 07:10:18 -0700 (PDT) Christoph Lameter wrote: > On Mon, 18 Sep 2006, Andrew Morton wrote: > > > On Mon, 18 Sep 2006 23:12:31 -0700 (PDT) > > Christoph Lameter wrote: > > > > > Hmmm... Actually one can get much better code. If I remove the padding > > > from struct zone then struct zone shrinks from 0x480 to 0x400 in length > > > > That padding is there to prevent the rather unrelated lru_lock and > > list_lock from falling into the same cacheline, which is presumed to be a > > bad thing... > > Yeah but we have added so much stuff in between that such a thing is > highly unlikely. Even with padding we could increase the size of zone to > the next power of two. unlikely != impossible. If some distro were to send the "unlikely" to zillions of users, that would be sad. I suspect what we want in there is to make the buddy-allocator's fields land in a separate cacheline from the vm-scanner's fields. I don't think the code has been reviewed for correctness wrt that for quite some time. If there's some smarter way of doing the padding then cool. Of course, it might be that we _want_ both things in the same cacheline: the page scanner often frees pages (we hope ;)). And it'll usually be the case that a page-allocator immediately goes and adds the page to the LRU. ANd ditto for a page-freer. Plus page-scanning is a much less common thing than page-allocating anyway. 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. -- 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