On Tue, 14 Jun 2011, David Gibson wrote:

> On Mon, Jun 13, 2011 at 09:06:16AM -0500, Andrew Hastings wrote:
> > On 06/08/2011 09:40 PM, Eric B Munson wrote:
> > > On Wed, Jun 8, 2011 at 8:50 PM, David Gibson
> > > <da...@gibson.dropbear.id.au>  wrote:
> [snip]
> > Actually, in thinking about this some more I wonder if the 
> > implementation ought to be using sbrk instead of mmap?  This would allow 
> > the initial part of the heap (which begins in the data segment) to be 
> > mapped by transparent hugepages, and would avoid putting a "hole" in the 
> > virtual address space between the initial part of the heap and the 
> > hugepage-aligned part.
> 
> Further reducing what the thp morecore option actually does.  I'm
> really not seeing quite what morecore=thp accomplishes; I thought the
> whole point of thp was that you'd get hugepgaes without having to do
> anything special at all.

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.

Eric

Attachment: 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

Reply via email to