Re: [PATCH] VM routine fixes
From: David Howells
Date: Wed Nov 10 2004 - 08:41:46 EST
Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote:
> > > this is nasty. The right thing would probably to swich !MMU arches
> > > to use the compount-page mechanism from the hugetlb code for this.
> > Supply me with a patch and I'll test it. I don't know how the
> > compound-page stuff works, but it's quite possibly the wrong way to do
> > it. There is no MMU available, so you can't generate adjacency that way.
> so look at the code. It's not about the MMU at all, it's about handling
> the Linux page structures. What you're doing is a big mess and should
> not be merged. So if you want to fix the issue do it properly.
It's not a big mess, and nor is it of my making; I'm just trying to make it
work. It's two tiny sections in page_alloc.c that have #ifdef variations
conditional on CONFIG_MMU. That's it. Full stop. Furthermore, it's not really
a mess at all. It's the least variation required to make the page allocator
also work in !MMU situations.
It's also a lot more efficient than the compound page stuff - though I'll
grant it won't necessarily catch the same errors - for the following reasons:
(1) get_page() and put_page() acquire extra conditional expressions.
(3) put_page() is out of line, not inline. This probably makes it less
efficient, especially given register clobberage.
(2) put_page() potentially has to access three struct pages per call, not
(4) prep_compound_page() and destroy_compount_page() are much bigger and more
complicated than the !MMU variations to which you're objecting.
I hope you also noticed that these are themselves #ifdef'd...
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
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.
Compound pages might be nice, but they're overkill.
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/