Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261403AbUKWTLT (ORCPT ); Tue, 23 Nov 2004 14:11:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261448AbUKWTJf (ORCPT ); Tue, 23 Nov 2004 14:09:35 -0500 Received: from mx1.redhat.com ([66.187.233.31]:32429 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S261403AbUKWRsj (ORCPT ); Tue, 23 Nov 2004 12:48:39 -0500 From: David Howells In-Reply-To: <20041123085608.3c30aa34.akpm@osdl.org> References: <20041123085608.3c30aa34.akpm@osdl.org> <20041123081129.3e0121fd.akpm@osdl.org> <20041122155434.758c6fff.akpm@osdl.org> <11948.1101130077@redhat.com> <29356.1101201515@redhat.com> <15564.1101228539@redhat.com> To: Andrew Morton Cc: torvalds@osdl.org, wli@holomorphy.com, hch@infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Compound page overhaul User-Agent: EMH/1.14.1 SEMI/1.14.5 (Awara-Onsen) FLIM/1.14.5 (Demachiyanagi) APEL/10.6 Emacs/21.3 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Date: Tue, 23 Nov 2004 17:48:18 +0000 Message-ID: <16887.1101232098@redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1636 Lines: 36 > So why did you create a "Compound page overhaul" in the first place? Was it > not to address some insufficiency for !MMU? Not entirely. Part of it was to improve for !MMU use, and part of it was it looked like I could improve it in general both by making it more readable and by things such as making page->private available on the head page. Linus suggested adding a CONFIG_COMPOUND_PAGE or something similar. By making half of the compound page stuff mandatory I could also get rid of some #ifdefs[*] for what appears to be a small overhead when allocating high-order pages when HUGETLBFS is not defined by making use of the fact that we'd be tickling the cache over the secondary page structures anyway. [*] People seem to want to give me the impression that #ifdefs are evil and should all be buried at least 10 feet down:-) This in turn provides a way to simplify a number of other things, such as the "free_pages" functions. There should be no overhead on single page handling when ENHANCED_COMPOUND_PAGES is not set. If it is set, then the overhead is pretty much the same as for hugetlbfs being compiled in now. > The current compound page logic should handle that quite happily, no? The current compound page implementation takes page->private away. What I've done gives it back, currently at the cost of one page flag bit, but there are ways around even that. David - 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/