On Tue, 2006-12-05 at 11:27 +1100, David Gibson wrote:
> On Mon, Dec 04, 2006 at 10:01:05AM -0600, Steve Fox wrote:
> > On Mon, 2006-12-04 at 13:14 +1100, David Gibson wrote:
> > > On Fri, Dec 01, 2006 at 05:01:21PM -0600, Steve Fox wrote:
> > > > Adam wanted to wait until after 1.0 was out the door to mess with this.
> > > > So here's my resubmission against current git.
> > > >
> > > > elflink: shrink the get_extracopy() function by breaking code
> > > > into new functions.
> > >
> > > Ah, yes.  I'd been meaning to ask about this for a while, but didn't
> > > get to it.  Can somebody explain to me what the get_extracopy()
> > > function is doing.  I mean, I understand it's trying to determine
> > > which parts of the BSS have already been used, and hence must be
> > > copied, but it's not clear to me the rationale or mechanism it's using
> > > for this.
> >
> > (re-adding libhugetlbfs-devel since you addressed 'somebody' rather than
> > myself)
> >
> > This comment pretty much sums it up. We find the highest address symbol
> > that meets these requirements and pick it as our upper copy limit.
> >
> > /*
> >  * To reduce the size of the extra copy window, we can eliminate certain
> >  * symbols based on information in the dynamic section.  The following
> >  * characteristics apply to symbols which may require copying:
> >  * - Within the BSS
> >  * - Global scope
> >  * - Object type (variable)
> >  * - Non-zero size (zero size means the symbol is just a marker with no
> >  *   data)
> >  */
> 
> Um.. ok.  And the rationale for this criterion?

Steve and I worked on this patch together some time ago...

The rationale is that libhugetlbfs arranges for itself to be initialized
second (just after it's only dependency glibc).  It is therefore
possible that constructor code besides our own has already run by the
time we get control.  These constructors are free to initialize
variables in the data segment.  We already copy the initialized data, so
we'll pick up modifications to those variables.  But we want to minimize
our copy of uninitialized data.

We have a fair amount of information about global symbols thanks to the
dynamic symbol table.  The 4 traits Steve mentions above can be used to
whittle down the list of BSS variables to a minimum set that could have
been written to by another library's constructor.  The highest address
occupied by one of these candidate variables is noted.

Armed with the address noted above, we copy the data segment, and the
first part of the bss up to that address.  This results in a much more
reliable copy and we've not seen any HUGETLB_MINIMAL_COPY related bugs
since it went in before 1.0.

-- 
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Libhugetlbfs-devel mailing list
Libhugetlbfs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libhugetlbfs-devel

Reply via email to