Re: [PATCH 2/5] NOMMU: High-order page management overhaul

From: David Howells
Date: Fri Dec 10 2004 - 11:17:22 EST


Andrew Morton <akpm@xxxxxxxx> wrote:

> > The attached patch overhauls high-order page handling.
>
> This patch (which is actually twelve patches)

How did you work that one out? Just because there're twelve points in my list
doesn't mean the patch can be split twelve ways. If you really want it
dissociating into sub-patches, I'm sure I can do that, but not all the
intermediate stages would be compilable and testable.

> seems to be taking out old code and replacing it with new code for no
> apparent reason.

(1) I've been moaned at by a lot of people for:

(a) #ifdefs in page_alloc.c... This gets rid of some of them, even if I
didn't add them.

(b) The way page_alloc.c was handling page refcounting differently under
nommu conditions. All I did was to fix it, but it seems it's my
fault:-/ This fixes it to use compound pages "as [I] should've done
in the first place".

(2) Splitting high-order pages has to be done differently on MMU vs
NOMMU. Part of this makes it simpler by providing convenience functions
for the job.

(3) More robust nommu high-order page handling. I'm wary of the current way
the individual secondary pages of a high-order page are handled in nomuu
conditions. I can see ways it can go wrong all too easily (the existence
of the whole thing is contingent on the count on the first page, but
pinning the secondary pages doesn't affect that).

(4) Making it easier to debug problems with compound pages (bad_page
changes).

(5) Abstraction of some compound page related functions, including a way to
make it more efficient to access the first page (PG_compound_slave).

> I mean, what is the *objective* of doing all of this stuff? What problems
> does it cause if the patch is simply dropped???

Objectives? Well:

(1) More robust high-order page handling in nommu conditions.

(2) Use compound pages to achieve (1) as per the numerous suggestions.

(3) Remove #ifdefs as per the numerous suggestions.

I think the drivers need a good auditing too. A lot of them allocate
high-order pages for various uses, some for use as single units, and some for
use as arrays of pages.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/