On Thu, Nov 06, 2008 at 10:08:27AM -0600, Adam Litke wrote:
> On Thu, 2008-11-06 at 10:15 +1100, David Gibson wrote:
> > On Wed, Nov 05, 2008 at 09:43:40AM -0600, Adam Litke wrote:
> > > On Wed, 2008-11-05 at 14:02 +0000, Mel Gorman wrote:
> > > > @@ -127,6 +140,34 @@ void *get_huge_pages(size_t len, ghp_t flags)
> > > > return NULL;
> > > > }
> > > >
> > > > +offset:
> > >
> > > This cache-coloring code (below) is nice. Could we move it into it's
> > > own function though? I like the idea of caching the sysconf value, but
> > > perhaps you could do that as a static variable within the new
> > > function.
> >
> > Yeah, I don't think this belongs in get_huge_pages().
> > get_huge_pages() is supposed to be the "raw" low-level interface to
> > just grab some hugepages. Offsetting within the page should be up to
> > the caller, if it cares.
>
> So the dispute is on how "smart" get_huge_pages() should be. I will
> agree that the name 'get_huge_pages' was perhaps a bad choice. While
> the name suggests a raw interface, it doesn't make sense to limit it to
> that because we already have two levels of raw interfaces. The maverick
> coder can choose to open() and mmap() files directly from any hugetlbfs
> they know about. Slightly more guidance is offered by the
> get_unlinked_fd() raw interface.
>
This is a good point. Someone looking for raw access to a hugepage backed
region with full control (including placement within the address space)
could do something like;
int hugepagesize = gethugepagesize()
int hugefd = hugetlbfs_unlinked_fd();
if (fd == -1) {
/* errno not necessarily useful so don't use perror() */
fprintf(stderr, "Woe, I die in the face now");
exit(EXIT_FAILURE);
}
char *mynewheap = mmap(...., hugefd, 0)
if (mynewheap == NULL) {
/* fallback */
mynewheap = mmap(NULL, ...., MAP_ANONYMOUS, ...);
}
They would have to handle prefaulting on kernels older than 2.6.27 but
you get the point. The interfaces for full control what is going on is
already there. Nothing is gained by deliberatly hobbling
get_huge_pages() from doing the Right Thing when it can.
> Then we move up to get_huge_pages(). My understanding was that this
> interface was meant to remove all intermediate steps that have been
> necessary to access huge page memory: one call, one buffer, ready to
> use. A buffer with potential cache-coloring performance issues is not
> ready to use in my view.
>
> --
> Adam Litke - (agl at us.ibm.com)
> IBM Linux Technology Center
>
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
-------------------------------------------------------------------------
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
