On Thu, Aug 09, 2007 at 04:48:22PM +1000, David Gibson wrote:
> On Wed, Aug 01, 2007 at 03:28:08PM -0700, Nishanth Aravamudan wrote:
> > On 01.08.2007 [17:17:25 -0500], Steve Fox wrote:
> > > On Mon, 2007-07-16 at 17:39 -0500, Andrew Hastings wrote:
> > > > Use dl_iterate_phdr(3) to eliminate the need to set
> > > > HUGETLB_FORCE_ELFMAP_EXECSTART.
> > > >
> > > > Tested on x86_64.
> > > >
> > > > -Andrew Hastings
> > > > Cray Inc.
> > > >
> > >
> > > I've tested this on PPC/x86/x86_64 using stream.c with combinations of
> > > RHEL5 and SLES10. There was no performance impact and the hugepage usage
> > > was the same. Looks good to me.
> > >
> > > Tested-by: Steve Fox <[EMAIL PROTECTED]>
> >
> > Excellent, thanks, Steve. Patch applied,
> > Nish
>
> Just had a chance to look at this properly. This bit worries me:
>
> /* Skip this object if it's not the main program */
> if (info->dlpi_addr)
> return 0;
>
> I'm not convinced this is a reliable way of determining which batch of
> program headers correspond to the main executable. On powerpc, at
> least, there appear to be *two* entries in the iteration with
> dlpi_addr == 0, I think the second one must be the VDSO. I'm also
> concerned that dlpi_addr might be non-zero for the main executable if
> it's a position independent executable (pie).
Oh... and it just occurs to me that prelinking might be a problem for
this too: I think that adjusts shared libraries so they can be loaded
with 0 bias address, which I believe is essentially what dlpi_addr
represents.
--
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
