On 16.08.2006 [21:23:59 +0100], Andy Whitcroft wrote:
> Nishanth Aravamudan wrote:
> > On 16.08.2006 [16:45:22 +0100], Andy Whitcroft wrote:
> >> Adam Litke wrote:
> >>> On Wed, 2006-08-16 at 08:12 -0700, Nishanth Aravamudan wrote:
> >>>> On 16.08.2006 [10:11:37 +0100], Andy Whitcroft wrote:
> >>>>> Nishanth Aravamudan wrote:
> >>>>>> morecore's comments indicate that we will failover to smallpage
> >>>>>> malloc if we run out of hugepages at runtime, but that is not
> >>>>>> the case. Modify one comment and remove another to not confuse
> >>>>>> anyone.
> >>>>>>
> >>>>>> Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
> >>>>>>
> >>>>>> diff --git a/morecore.c b/morecore.c index 9f13316..08a356b
> >>>>>> 100644 --- a/morecore.c +++ b/morecore.c @@ -45,8 +45,8 @@
> >>>>>> static long mapsize; * pretend there are none this covers us
> >>>>>> for the case where another * map is in the way. This is
> >>>>>> required because 'morecore' must have * 'sbrk' semantics, ie.
> >>>>>> return sequential, contigious memory blocks. - * Luckily, if
> >>>>>> it does not do so and we error out malloc will happily - * go
> >>>>>> back to small pages and use mmap to get them. Hurrah. + *
> >>>>>> Sufficient hugepages must be allocated before the malloc calls,
> >>>>>> or + * the application will be killed.
> >>>>> Hmmm, that is a tricky one. If morecore does return failure
> >>>>> then the malloc library will do all the things mentioned. The
> >>>>> problem here is that with demand fault semantics we will say
> >>>>> 'yes' and return a page which can't be instantiated.
> >>>>>
> >>>>> The comment in and of itsself is correct IMO. Your caveat is
> >>>>> appropriate though in addition.
> >>>> Description: morecore's comments indicate that we will failover
> >>>> to smallpage malloc if we run out of hugepages at runtime. While
> >>>> that is the case, the semantics of demand faulting require
> >>>> sufficient hugepages exist before the malloc calls. Add a comment
> >>>> to that effect to make it clear.
> >>>>
> >>>> Signed-off-by: Nishanth Aravamudan <[EMAIL PROTECTED]>
> >>>>
> >>>> diff --git a/morecore.c b/morecore.c index 9f13316..4b222ed
> >>>> 100644 --- a/morecore.c +++ b/morecore.c @@ -46,7 +46,9 @@ static
> >>>> long mapsize; * map is in the way. This is required because
> >>>> 'morecore' must have * 'sbrk' semantics, ie. return sequential,
> >>>> contigious memory blocks. * Luckily, if it does not do so and we
> >>>> error out malloc will happily - * go back to small pages and use
> >>>> mmap to get them. Hurrah. + * go back to small pages and use
> >>>> mmap to get them. Hurrah. However, + * sufficient hugepages must
> >>>> be allocated before the malloc calls, or + * the application will
> >>>> be killed. */
> >>> How about this:
> >>>
> >>> * go back to small pages and use mmap to get them. Hurrah.
> >>> However, * due to the semantics of demand faulting combined with
> >>> MAP_PRIVATE mappings in newer kernels, we are unable to detect the
> >>> out of huge pages condition and cannot return an error to glibc
> >>> for that case. The result is that when enough huge pages don't
> >>> exist to satisfy the application's requirements, it may be killed
> >>> at runtime.
> >>>
> >> I'd also make the "However" clause a separate paragraph. /me had
> >> more this in mind ...
> >
> > Works for me :)
>
> Ok, we have all this talk about how it all goes bang and doesn't
> work... but then there was this commit below, which I'd expect to
> restore the semantic? Or did I miss something.
You missed something... a subsequent commit:
> commit 3da5975d7e12aebd8d7614f48d8c0d68c6a03146
> Use mlock to reserve newly allocated hugepages in hugetlb_morecore.
>
> Since MAP_PRIVATE allocations are full overcommit, the mmap call
> can succeed even if there aren't enough huge pages to satisfy the
> mapping. Thus fallback
> to normal pages is not currently possible. Use mlock to
> instantiate the newly
> allocated area and if that fails, release it and initiate fallback
> to normal pages.
commit f31fda38c96d51cf65a5c2be416950fe14a3fd96
Author: aglitke <[EMAIL PROTECTED]>
Date: Tue Jun 6 14:36:50 2006 -0500
Revert mlock() reservation in hugetlbfs_morecore
Use of mlock is disabled because it results in bad numa behavior since the
malloc'd memory is allocated node-local to the cpu calling morecore() and
not
to the cpu(s) that are actually using the memory.
Thanks,
Nish
--
Nishanth Aravamudan <[EMAIL PROTECTED]>
IBM Linux Technology Center
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Libhugetlbfs-devel mailing list
Libhugetlbfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
