On Tue, Dec 05, 2006 at 08:57:31AM -0600, Adam Litke wrote:
> 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.
Yes, yes, yes, I know what the code's *for*, I'm trying to find out
why it works.
> 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.
Ok, but why is that the criterion? That's the rationale I'm after.
> 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.
--
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
-------------------------------------------------------------------------
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
