Eric B Munson wrote: > On Wed, 15 Jun 2011, Andrew Hastings wrote: >> My opinion: There's no reason for HUGETLB_MORECORE=thp to _not_ do the >> madvise. HUGETLB_MORECORE=thp should be implemented as a wrapper around >> sbrk; it should _not_ add a gap to the heap. > > I am fine having madvise be the default and the next version will do it this > way. I don't think the loss of 2m-4k of address space (only) is a big enough > issue to justify having thp implement a completely new morecore hook.
A few thoughts: - A new morecore hook would be pretty simple; just madvise+sbrk, I'd think, after some hugepage size rounding. And maybe some mallopt calls. - The gap has some downsides: 1. It's mildly confusing to users. Why does /proc/<pid>/maps show such a small heap? What is that memory segment (not reported as [heap]) following the gap? 2. It can actually result in wasted memory. The last 4K page before the gap could be almost entirely unused if the initial part of the heap uses just the first part of the page and all subsequent malloc calls are larger than can be satisfied by the remainder of the page. -Andrew Hastings Cray Inc. ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev _______________________________________________ Libhugetlbfs-devel mailing list Libhugetlbfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
