Re: RFC: Transparent Hugepage support

[Dave Hansen <dave@linux.vnet.ibm.com>]

On Tue, 2009-11-03 at 12:18 +0100, Andrea Arcangeli wrote:
> On Sun, Nov 01, 2009 at 08:29:27AM +1100, Benjamin Herrenschmidt wrote:
> > This isn't possible on all architectures. Some archs have "segment"
> > constraints which mean only one page size per such "segment". Server
> > ppc's for example (segment size being either 256M or 1T depending on the
> > CPU).
> 
> Hmm 256M is already too large for a transparent allocation. It will
> require reservation and hugetlbfs to me actually seems a perfect fit
> for this hardware limitation. The software limits of hugetlbfs matches
> the hardware limit perfectly and it already provides all necessary
> permission and reservation features needed to deal with extremely huge
> page sizes that probabilistically would never be found in the buddy
> (even if we were to extend it to make it not impossible).

POWER is pretty unusual in its mmu.  These 256MB (or 1TB) segments are
the granularity with which we must make the choice about page size, but
they *aren't* the page size itself.

We can fill that 256MB segment with any 16MB pages from all over the
physical address space, but we just can't *mix* 4k and 16MB mappings in
the same 256MB virtual area.

16*16MB pages are going to be hard to get, but they are much much easier
to get than 1 256MB page.  But, remember that most ppc64 systems have a
64k page, so the 16MB page is actually only an order-8 allocation.
x86-64's huge pages are order-9.  So, it sucks, but allocating the pages
themselves isn't that big of an issue.  It's getting a big enough
virtual bunch of them together without any small pages in the segment.

-- Dave

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>