On 15.02.2008 [11:52:39 +1100], David Gibson wrote:
> On Thu, Feb 14, 2008 at 11:48:42AM -0600, Andrew Hastings wrote:
> > Disable heap shrinking by default unless HUGETLB_MORECORE_SHRINK=yes is
> > set in the environment.
> >
> > If malloc allocates memory on the heap before libhugetlbfs's
> > setup_morecore is called, then when malloc calls hugetlbfs_morecore
>
> Hrm... thing is, I'm pretty sure we're already in deep trouble if
> malloc() is called before our setup_morecore(). Most of the various
> link issues we've had to deal with have been about ensuring that the
> libhugetlbfs constructor goes as early as possible, before everything
> except libc itself, so that we can establish our morecore hooks before
> anyone attempts to use the heap. Well, and so that segment remapping
> also goes early, which is even more stuffed if things like malloc()
> have been called first.
So my experience is this: we don't actually fail most (none I can think
of) binaries even if we skip in the address space from the smallpage
heap when our constructor runs in morecore. I have question, though:
We currently (well before heap shrinking was added) don't ever trim the
heap back. That means ... couldn't we violate brk() semantics for the
hugepage heap? That is we currently have the following:
/* if this is the first map */
if (! mapsize) {
if (heapbase && (heapbase != p))
WARNING("Heap originates at %p instead of %p\n",
p, heapbase);
/* then setup the heap variables */
heapbase = heaptop = p;
}
for starting the heap (violating brk() already...), but then have:
else if (p != (heapbase + mapsize)) {
/* Couldn't get the mapping where we wanted */
munmap(p, delta);
WARNING("Mapped at %p instead of %p in hugetlbfs_morecore()\n",
p, heapbase + mapsize);
return NULL;
}
That is, when the heap is forced to jump after we've started the heap,
we fail. But couldn't we keep going, since we don't trim it back down?
Does glibc enforce brk() semantics internally? I'd think it treats
morecore as a valid source until it gets NULL? But I don't know the
expected semantics well enough.
Thanks,
Nish
--
Nishanth Aravamudan <[EMAIL PROTECTED]>
IBM Linux Technology Center
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libhugetlbfs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
