On Mon, Feb 25, 2008 at 08:23:48PM -0800, Nishanth Aravamudan wrote:
> 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.
Um.. sorry. I'm completely failing to grasp what you're getting at.
What aspect of this behaviour will break what?
--
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
-------------------------------------------------------------------------
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
