On 28.02.2008 [20:33:20 +1100], David Gibson wrote:
> On Wed, Feb 27, 2008 at 11:31:48PM -0800, Nishanth Aravamudan wrote:
> > On 27.02.2008 [23:20:35 -0800], Nishanth Aravamudan wrote:
> > > On 28.02.2008 [13:55:58 +1100], David Gibson wrote:
> > > > On Wed, Feb 27, 2008 at 06:34:37PM -0800, Nishanth Aravamudan wrote:
> > > > > On 28.02.2008 [13:28:47 +1100], David Gibson wrote:
> > > > > > On Wed, Feb 27, 2008 at 06:17:02PM -0800, Nishanth Aravamudan wrote:
> > > > [snip]
> > > > > > > Hrm, I guess I hadn't thought about it that way. I really am
> > > > > > > curious
> > > > > > > about these semantics. We already have cases where a small page
> > > > > > > [heap]
> > > > > > > exists in a processes address space, say at 0x10000000 for a
> > > > > > > 32-bit
> > > > > > > process and we start the hugepage heap in the morecore
> > > > > > > constructor at
> > > > > > > 0x20000000. If glibc thought it could use that entire area, but we
> > > > > > > didn't actually allocate any pages for it to use there, does it
> > > > > > > just
> > > > > > > take a bunch of page faults?
> > > > > >
> > > > > > We really have such cases? I wouldn't have expected that to work.
> > > > >
> > > > > We definitely do. It's been a source of confusion for the testers, but
> > > > > it does seem to work. And given the code I pasted earlier in the
> > > > > thread
> > > > > (from morecore.c), it's clearly been coded to be a non-failure case if
> > > > > the first mmap() is moved (mapsize == 0), but if we've already
> > > > > allocated
> > > > > any of the heap, we fail.
> > > >
> > > > Hrm. Have we checked in these cases that malloc() or (glibc's
> > > > default) morecore is actually being called before our version. I'm
> > > > wondering if it might just be that the tail end of the BSS is being
> > > > labelled "[heap]" in /proc/pid/maps, but we don't actually have a heap
> > > > from the glibc allocator's point of view.
> > >
> > > Hrm, I suppose that could be true. maps sees the brk() and says [heap]
> > > must be there, but it might not be.
> > >
> > > How would we (I) figure out if malloc() or morecore has been called
> > > before us?
> >
> > Actually thinking about it, I suppose strace() could help a little?
>
> Indeed. As might ltrace. Or even run under gdb and put a breakpoint
> on morecore.
True, very true. I will try to do this later this week or early next.
> > Looking at the kernel, the following snippet from fs/proc/task_mmu.c is
> > the relevant bit:
> >
> > if (vma->vm_start <= mm->start_brk &&
> > vma->vm_end >= mm->brk) {
> > name = "[heap]";
> > } else if (vma->vm_start <= mm->start_stack &&
> > vma->vm_end >= mm->start_stack) {
> > name = "[stack]";
> > }
> >
> > So if the VMA we're looking at starts at or before the original brk()
> > and ends at or after the current brk(), it's considered the heap.
> >
> > How would that be the case if it's the tail-end of the heap, since we
> > are not setting the brk()?
>
> Well, possibly it can't. But if the start and end values are rounded
> out to a page size, could that trigger this test, even without the
> break moving?
That's a good point. Certainly seems possible, I suppose. I will take a
look at the applications I've seen this with and try get us some info.
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
