On Thu, 2007-11-15 at 12:26 +1100, David Gibson wrote:
> 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.
Adam suggested that perhaps it was added after the address range
restriction was removed, but to work around any applications that
hard-coded values within that range.
> Err... plus ALIGN(0x18000000000) really makes no sense (as opposed to
> . = 0x18000000000)
Yeah, that struck me as wrong too.
> 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.
Adam and I discussed that too, but we weren't sure if we should be
concerned about it since we're not currently aware of any apps that
would make it fail.
Unfortunately I can't seem to get a large alignment to work as I'd
expect at the end of the BSS. No matter how I define it,
. = ALIGN(0x10000000000)
or
. = 0x20000000000
I still get the same memsz padding for the BSS:
LOAD off 0x0000000000020000 vaddr 0x0000010000000000 paddr
0x0000010000000000 align 2**16
filesz 0x0000000000000004 memsz 0x0000000100000000 flags rwx 100000
and therefore the heap never fails to begin right in the same segment,
which is obviously a problem.
10000000000-10000010000 rwxp 00020000 08:11 275877
/root/speccpu06/benchspec/CPU2006/410.bwaves/run/run_peak_ref_none.0000/bwaves_peak.none
10000010000-10100030000 rw-p 10000010000 00:00 0 [heap]
--
Steve Fox
IBM Linux Technology Center
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libhugetlbfs-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel
