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 <sys/file.h>
> #include <linux/unistd.h>
> #include <sys/mman.h>
> +#include <sys/wait.h>
> #include <errno.h>
> #include <limits.h>
> #include <elf.h>
> @@ -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.
--
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: 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel