On Monday 17 September 2007, Adam Litke wrote: > 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.
Now that we have Mel's mobility patches to make it feasible to dynamically allocate huge pages, I'd say it's definitely time to get this patch in. Users will really appreciate not having to preallocate huge pages for all possible workloads. Dave Acked-by: Dave McCracken <[EMAIL PROTECTED]> ------------------------------------------------------------------------- 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
