Re: [PATCH 00 of 41] Transparent Hugepage Support #17

[Andrea Arcangeli <aarcange@redhat.com>]

On Mon, Apr 12, 2010 at 11:44:51AM +0100, Mel Gorman wrote:
> As a side-note, this is what dynamic hugepage pool resizing was for.
> 
> hugeadm --pool-pages-max <size|DEFAULT>:[+|-]<pagecount|memsize<G|M|K>>
> 
> The hugepage pool grows and shrinks as required if the system is able to
> allocate the huge pages. If the huge pages are not available, mmap() returns
> NULL and userspace is expected to recover by retrying the allocation with
> small pages (something libhugetlbfs does automatically).

If 99% of the virtual space is backed by hugepages and just the last
2M have to be backed by regular pages that's fine with us, we want to
use hugepages for the 99% of the memory.

> In the virtualisation context, the greater problem with such an approach
> is no-overcommit is possible. I am given to understand that this is a
> major problem because hosts of virtual machines are often overcommitted
> on the assumption they don't all peak at the same time.

Yep, other things that come to mind is that we need KSM to split and
merge hugepages when they're found equal, not yet working right now
but it's more natural to do it in the core VM as KSM pages then have
to be swapped too and mixed in the same vma with regular pages and
hugepages.

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