On Mon, 2007-10-15 at 10:53 +1000, David Gibson wrote:
> On Fri, Oct 12, 2007 at 02:30:16PM -0500, Steve Fox wrote:
> > On Fri, 2007-10-12 at 15:26 +1000, David Gibson wrote:
> >
> > > Actually, it doesn't necessarily need using named hugepage files: we
> > > could fork() after obtaining the fd, but before mapping it.
> >
> > Adam pointed that out to me as I was re-working this patch to use your
> > fork() suggestion. Sorry, I've been sitting on this patch while working
> > on the other half of a problem.
> >
> >
> > elflink: prevent segfault on 32bit PPC apps with large stack
> >
> > [PPC] Prior to memory slices being added in 2.6.22, our temporary hugetlbfs
> > mappings are created in the segment below the stack. If a 32-bit PPC app
> > grows its stack larger than one segment, it will segfault because the
> > neighboring segment has been marked as "hugepage-only".
> >
> > Providing a hint address for our temporary mappings is unreliable because,
> > prior to 2.6.22, if the hint address is invalid get_unmapped_area()
> > simplistically started at the top of the address space and searched down.
> > This means we could end up with the kernel picking an address that's higher
> > than the hint address.
> >
> > To get around this limitation, David Gibson suggested forking a child to
> > perform the temporary hugetlbfs mappings in its own address space to avoid
> > tainting segments in the parent's. I have also measured a small performance
> > improvement, which Adam believes may be due to SLBs.
>
> Hrm. Interesting. Is that with slice or pre-slice kernel code?
>
> >
> > Signed-off-by: Steve Fox <[EMAIL PROTECTED]>
> > ---
> >
> > diff --git a/elflink.c b/elflink.c
> > index 4fce9b9..f7f5ebb 100644
> > --- a/elflink.c
> > +++ b/elflink.c
> > @@ -32,6 +32,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -881,6 +882,41 @@ static int find_or_prepare_shared_file(struct seg_info
> > *htlb_seg_info)
> > return -1;
> > }
> >
> > +#if defined (__powerpc__) && !defined (__LP64__)
> > +static int arch_prepare_segment(struct seg_info *htlb_seg_info)
>
> I don't see that there's any point doing this on a per-arch basis.
> Although it's only really necessary for powerpc, I suggest we do it
> this way always just for simplicity.
We thought of this, but x86 takes a pretty painful performance hit.
Steve may have details on just how bad it is.
--
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
Libhugetlbfs-devel mailing list
Libhugetlbfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
