Re: RFC: Transparent Hugepage support

[Andrea Arcangeli <aarcange@redhat.com>]

Hello Christoph,

On Thu, Oct 29, 2009 at 02:51:11PM -0400, Christoph Lameter wrote:
> How would glibc do that?

So the first important thing is to start the mapping at 2M aligned
virtual address. Second important thing is to always do sbrk
increments in 2M chunks and mmap extensions in 2M chunks with a mmap
on the next 2M (mremap right now calls split_huge_page but later we
will teach mremap and mprotect not to call split_huge_page and to
handle the pmd_trans_huge natively so they can run a bit faster).

With those two precautions all page faults will be guaranteed to map
2M pages if they're available (and then fragmentation will decrease
too as 2M pages will be retained in the mappings).

Even after split_huge_page, the pte will point to the same 2M page as
before. And when task is killed all 2M pages will be recombined in the
buddy. Page coloring will also be still guaranteed (up to the 512th
color of course) even after split_huge_page run.

But if split_huge_page is called because munmap is unmapping just a 4k
piece of a 2M page, then split_huge_page will be called to free just
that 4k piece so fragmentation will be created. So the last precaution
that glibc should use is to munmap (or madvise_dontneed) in 2M chunks
naturally aligned to make sure not to create unnecessary
fragmentation.

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