Adam Litke wrote: > *** Series updated to remove locked_vm accounting > The upper bound on pool growth is governed by per-filesystem quotas which > maintains the global nature of huge page usage limits. Per process accounting > of hugepages as locked memory has been pulled out of this patch series as it > is > logically separate, and will be pushed separately. > *** > > In most real-world scenarios, configuring the size of the hugetlb pool > correctly is a difficult task. If too few pages are allocated to the pool, > applications using MAP_SHARED may fail to mmap() a hugepage region and > applications using MAP_PRIVATE may receive SIGBUS. Isolating too much memory > in the hugetlb pool means it is not available for other uses, especially those > programs not using huge pages. > > The obvious answer is to let the hugetlb pool grow and shrink in response to > the runtime demand for huge pages. The work Mel Gorman has been doing to > establish a memory zone for movable memory allocations makes dynamically > resizing the hugetlb pool reliable within the limits of that zone. This patch > series implements dynamic pool resizing for private and shared mappings while > being careful to maintain existing semantics. Please reply with your comments > and feedback; even just to say whether it would be a useful feature to you. > Thanks. > >
kvm with newer hardware (that supports nested paging) stands to benefit greatly from this. backing guest memory with huge pages significantly decreases tlb miss costs, and allows using huge tlb entries for guest kernel mappings. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Libhugetlbfs-devel mailing list Libhugetlbfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
