Re: [PATCH] VM routine fixes

From: Andrew Morton
Date: Wed Nov 10 2004 - 14:03:17 EST


David Howells <dhowells@xxxxxxxxxx> wrote:
>
> Compound pages seem to be in some way tied to the TLB entry coverage sizes
> available (for hugetlb), so it's not obvious that it's permitted to have
> compound pages not of these sizes, and as I need to allocate arbitrary
> sizes...

We've considered enabling compound pages permanently. We thought sparc64
might want that, and it simplifies coverage testing. But the
conditionality has been left in for now as a microoptimisation.

> If I am correct about this, then the !MMU problem would still exist - just
> with adjacent sets of compound pages rather than adjacent sets of pages.

Why _does_ !CONFIG_MMU futz around with page counts in such weird ways
anyway? Why does it have requirements for higher-order pages which differ
from !CONFIG_MMU?

If someone could explain the reasoning behind the current code, and the FRV
enhancements then perhaps we could work something out.

> Compound pages might be nice, but they're overkill.

I don't expect they have significant performance overhead, because they'll
only add cycles for higher-order pages. They're rare, and are already
rather inefficient.
-
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/