lkml.org 
[lkml]   [2004]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Compound page overhaul
Date

> 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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:2.468 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site