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