This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2][RFC] #17645, fix slow DSO sorting behavior in dynamic loader
- From: Chung-Lin Tang <chunglin_tang at mentor dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: <cltang at codesourcery dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sat, 10 Aug 2019 19:49:17 +0800
- Subject: Re: [PATCH 1/2][RFC] #17645, fix slow DSO sorting behavior in dynamic loader
- Ironport-sdr: tdoHoByhSC7PBAZ7TtHEHaDVF7yg5o2CLqpjtbizCw2EpSIbHL8qOKItHbXsThnLTOzymbfCIf 7Q9vVimQ/wgAInUiScALGf6zjgKPzbqlA+Vg9LmQ03SuEeFC9Y5cwt5r+Bgy9C3nlfewnl0uti mUlGKUvQH5fghM7XowSgB8RZ6ASg5UgvaA8MByBLb+EL3N/ZOm8Nhz+6usyFElIY0IkPK2Dpot sRNU4tBDjYp/3fRFK6M0EHk74O7vzGxJwo2S9LY/x3XM/CDaGM7TBDlm71JrQapMUT+fY+6f9k 6Tw=
- Ironport-sdr: H9HG0V8kCDfeNBeP3n85MyMM3T52F7HWbWAFzKhXmtgBt1iSx2FdOwb7ZMK70PCGuSJ+JXQGNl an2VVC0Wlr0IFAwJq5ibxXP4l20FVakIhv7rKVnUhxNdvUfv3HDYEUQX2gjtZ34UhDaVHpLSv+ KA25UrpHGAoeur3vMuUYamOIaiNOcjT76WLnj6rp/pFeK2nG50hgZWa9B2QDG9YRkmV3EFftRr F+rTmTYzLDy9QdGc2O6WCTqO7LC1gXo7ZioimcBjBh/4z3oFdY79cNOk7KCzlIu0rweGcZ5s4i S68=
- References: <bb13d870-a1f2-94fa-cf9e-9d78ad1fe4ee@mentor.com> <87h87crimv.fsf@oldenburg2.str.redhat.com> <fd8d80af-c01d-0f2d-8082-ecc8c5537600@mentor.com> <87wog15fyy.fsf@oldenburg2.str.redhat.com> <e869a2d2-3717-9491-1bd3-03805e0dffce@mentor.com> <87mugnao17.fsf@oldenburg2.str.redhat.com>
- Reply-to: <cltang at codesourcery dot com>
On 2019/8/5 6:45 PM, Florian Weimer wrote:
What I did in the ld.so code patch was add a second pass of sorting
that ignores runtime deps, prioritizing link dependencies; this
appears to also be what prior discussion pointed towards, see more
details in that 2nd email with the actual code patch.
I wonder if it makes sense to disentangle this (desirable) functional
change from the rest (which sould be purely an optimization).
By "functional change" here, are you referring to the testing framework,
or the described ld.so destructor behavior I described above?
The destructor behavior.
Well, I'm definitely not suggesting adding the two-pass sorting described
above with the current sorting algorithm (even if it should be relatively
straightforward to do so)
The entire #17645 issue is due to the current algorithm becoming prohibitively
slow in certain pathological cases. Trying to fix the destructor behavior that
way without replacing the current sorting algorithm will greatly exacerbate
the performance problem.
Is it even necessary to re-sort on dlclose? Is the original dependency
order available somewhere? Then we could make it explicit that the
destructor order is the reverse of the constructor order (for the
objects unloaded). Or is there a corner case which causes an expected
divergence?
Dynamic loaded objects could add more relocation dependencies, and
thus augment the dependency relations (by adding more constraints), so
a final sort should still be required.
Yes, these dynamically added relocation dependencies could mean that
fewer objects than had been loaded by the dlopen can be freed with
dlclose. But if we disregard those relocation dependencies for
destructor order sorting, wouldn't be the sorted result equivalent to
the constructor order?
Relocation dependencies are not completely disregarded during destruction,
just that they're prioritized lower than static link dependencies (when
dependence cycles cause ambiguity in determining a single ordering), hence
the two passes of sorting. Besides that, dlopen'ed but not dlclose'd objects
also need to be processed along, so any existing already-computed ordering
is probably not enough in the general case.
Chung-Lin