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@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>