On Wed, Nov 14, 2007 at 09:21:44AM -0600, Steve Fox wrote:
> David,
>
> Currently, the elf64ppc.xB linker script is the only script which places
> its hugepages in 1TB segments. This appears to be due to an old
> restriction which you fixed long ago in commit
> c594adad5653491813959277fb87a2fef54c4e05 where hugepages had to reside
> between 1TB and 1.5TB in the address space. Since no other scripts do
> this currently, I'm guessing this script just got missed when the limit
> was removed.
Well, from the comment, I think the 1.5TB value was there attempting
to make the script work with *both* old kernels that have the 1-1.5TB
restriction and newer kernels with the dynamic hugepage area.
Execpt of course, that that wouldn't work, since it would put the
hugepage segment just *outside* the hugepage area on the old kernels.
Err... plus ALIGN(0x18000000000) really makes no sense (as opposed to
. = 0x18000000000)
Aligning to 256MB, as you do in this patch, is not correct - even
considering only newer kernels. If the text/data segments are really
huge, they may pust the BSS up above 4GB, in which case we need to
move all the way out to 1TB to get into the next slice. So in fact
the minimal alignment for dynamic hugepage kernels is:
. = (. >= 0x100000000) ? ALIGN(0x10000000000) : ALIGN(0x10000000)
But it seems simpler to just always align to 1TB, since that should
always be safe.
> Prior to this patch, running most SpecOMP (and some SpecCPU) benchmarks
> with the XL compilers would result in this error:
>
> libxlfmath initialization: dlopen failed for libm.so: dlopen: invalid
> caller
>
> I'm still trying to figure out exactly why it's failing with the 1.5TB
> alignment, but I thought I'd run this by you for some insight.
Yeah, I don't understand why that wouldn't work.
>
> Thanks.
>
> diff --git a/ldscripts/elf64ppc.xB b/ldscripts/elf64ppc.xB
> index 030840e..ffd8166 100644
> --- a/ldscripts/elf64ppc.xB
> +++ b/ldscripts/elf64ppc.xB
> @@ -182,10 +182,7 @@ SECTIONS
> /* Hugepage area */
> /* Saving hugepages is more important than saving executable size, so
> * we don't attempt to maintain congruence here */
> - . = ALIGN(0x18000000000); /* Move into next 1TB area, but use 1.5TB
> - * instead of 1TB for compatibility with
> - * old kernels that have a fixed hugepage
> - * range */
> + . = ALIGN(256*1024*1024);
> /* HACK: workaround fact that kernel may not cope with segments with zero
> * filesize */
> .hugetlb.data : { LONG(1) } :htlb
> @@ -203,7 +200,8 @@ SECTIONS
> *(.dynbss)
> *(.bss .bss.* .gnu.linkonce.b.*)
> *(COMMON)
> - }
> + . = ALIGN(256*1024*1024);
> + } :htlb
> _end = .;
> PROVIDE (end = .);
> /* Stabs debugging sections. */
>
--
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
