Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH] Compound page overhaul | Date | Tue, 23 Nov 2004 17:48:18 +0000 |
| |
> 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/
| |