On Thu, Nov 06, 2008 at 11:27:23AM +0000, Eric B Munson wrote: > On Thu, 06 Nov 2008, Mel Gorman wrote: > > > > > We just want to provide an interface suitable for people that writing > > allocators or are porting parts of their application to use hugepages where > > it is sensible. The former should be already coding to not waste any memory > > and the latter should be helped as much as possible by defaulting to > > behaviour > > whose performance does not suck. > > > > I tend to agree with Mel here, the purpose of libhugetlbfs is to > make huge pages easy and attractive to use. I think that having > such a serious performance hit when using get_huge_pages with no > explanation is likely to turn developers off. Even if the need for > some thought when using get_huge_pages is documented I doubt that > the average developer is going to look at libhuge source or man > pages when hunting for performance problems. > > That being said, I understand that the function name might imply > that it is a simple interface for grabbing memory backed by huge > pages. Perhaps a new function should be introduced and use of > get_huge_pages deprecated unless you know what you are getting into.
That would be just what I'm suggesting...
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
signature.asc
Description: Digital signature
------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________ Libhugetlbfs-devel mailing list Libhugetlbfs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
