On Wed, 15 Jun 2011, Andrew Hastings wrote: > Eric B Munson wrote: > >It is true that you will end up with huge pages for the heap eventually > >without > >changing anything. khugepaged will promote areas it finds that are 2MB > >aligned, etc. However, it is possible to have things _allocated_ as > >transparent huge pages without requiring promotion. To do this, the > >allocation > >needs to be 2MB aligned. This is what morecore=thp does, it ensures that > >_all_ > >heap allocations start life as transparent huge pages and will not require > >promotion unless they are split. > > > >I am fine changing the morecore option to be thp and thp+ (or maybe just > >madvise) where the latter implies thp. I do think that having thp without > >madvise is useful for the reasons stated above. > > Maybe we should look at where HUGETLB_MORECORE=thp (as currently proposed) > adds value. > > 1. /sys/kernel/mm/transparent_hugepage/enabled = never. > > HUGETLB_MORECORE=thp adds no value. Arguably, it makes things worse by > putting a gap in the heap.
I would argue that this is a configuration issue, why would anyone start a program with morecore=thp without enabling kernel support. This is the same as saying morecore=yes without mounting hugetlbfs or allocating anything to the huge page pool, a situation that we already support. > > 2. /sys/kernel/mm/transparent_hugepage/enabled = madvise. > > HUGETLB_MORECORE=thp adds no value unless HUGETLB_THP_MADVISE is set. > > If HUGETLB_THP_MADVISE is _not_ set, arguably makes things worse by putting a > gap in the heap. > If HUGETLB_THP_MADVISE _is_ set, puts the heap on hugepages, but leaves a gap > in the heap. Again, configuration issue. I don't think it is too much to assume the user will know something about how the system is configured. > > 3. /sys/kernel/mm/transparent_hugepage/enabled = always. > > HUGETLB_MORECORE=thp may or may not add some value. The heap ought to end up > on hugepages even without libhugetlbfs as long as the heap is large enough. > HUGETLB_MORECORE=thp may result in small heaps ending up on hugepages, but > unfortunately it puts a gap in the heap. It _does_ add value by ensuring that the entire heap ends up on huge pages without requiring the user to care about allocation sizes or address alignments. The gap you are referring to is at most 2m-4k and the morecore hook protects against bumping into it accidentally. The situation of small heaps ending up in huge pages is the same as the case where morecore=yes for small heaps. > > 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.
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ 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
