From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 5 Apr 2007 19:40:15 +0100 (BST) From: Hugh Dickins Subject: Re: [RFC] Free up page->private for compound pages In-Reply-To: Message-ID: References: <20070405033648.GG11192@wotan.suse.de> <20070405035741.GH11192@wotan.suse.de> <20070405042502.GI11192@wotan.suse.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Christoph Lameter Cc: Nick Piggin , linux-mm@kvack.org, dgc@sgi.com List-ID: On Thu, 5 Apr 2007, Christoph Lameter wrote: > On Thu, 5 Apr 2007, Hugh Dickins wrote: > > > > static inline int page_count(struct page *page) > > > { > > > - if (unlikely(PageCompound(page))) > > > - page = (struct page *)page_private(page); > > > - return atomic_read(&page->_count); > > > + return atomic_read(&compound_head(page)->_count); > > > } > > > > No, you don't want anyone looking at the page_count of a page > > currently under reclaim, or doing a get_page on it, to go veering > > off through its page->private (page->first_page comes from another > > of your patches, not in -mm). Looks like you need to add a test for > > PageCompound in compound_head (what a surprise!), unfortunately. > > Hmmm... Thus we should really have separate page flag and not overload it? Of course that would be more efficient, but is it really something we'd want to be spending a page flag on? And it's mainly a codesize thing, the initial unlikely(PageCompound) tests should keep the main paths as fast as before, shouldn't they? But I did wonder whether you could do it differently, but not setting PageCompound on the first struct page of the compound at all - that one doesn't need the compound page adjustment, of course, which is your whole point. Then in those places which really need to know the first is compounded, test something like PageCompound(page+1) instead. "something like" because that particular test won't work nicely for the very last struct page in a ... node? (sorry, I don't know the right terminology: the last struct page in a mem_map-like array). But if that ends up peppering the code with PageCompound(page) || PageCompound(page+1) expressions on fast paths, it'd be a whole lot worse than the PageCompound(page) && PageTail(page) we're envisaging. Hugh -- 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