On Mon, Feb 25, 2008 at 09:05:42PM -0800, Nishanth Aravamudan wrote:
> On 26.02.2008 [15:33:55 +1100], David Gibson wrote:
> > 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?
>
> If we keep trimming disabled, and allow the hugepage heap to jump in the
> address space (presumably because we're on power and something
> (/lib/ld-2.4.so for a 32-bit binary seems to be the common case) backed
> by small pages is in the way of a large mmap() [512M or so]), will that
> break applications?
Um.. I don't see how the hugepage heap can jump. That's the whole
point of that else case, if we can't allocate following on from our
existing heap, we fail the morecore.
> In code, that is the following in the second conditional above:
>
> else if (p != (heapbase + mapsize)) {
> /* Couldn't get the mapping where we wanted
> Continue anyways, because we won't free it back */
> WARNING("Mapped at %p instead of %p in hugetlbfs_morecore()\n",
> p, heapbase + mapsize);
> }
>
> That is, we don't munmap the most recently created mapping and we don't
> return NULL to malloc().
Except that we do munmap() and we do return NULL to malloc().
Even more confused now...
--
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
