prelink: is it worth it?
John Reiser
jreiser at BitWagon.com
Sat Jul 11 18:15:36 UTC 2009
> [benefit of prelink:]
> - almost all relocations a program has to perform are avoided. These
> can be very expensive when many dependencies and/or large symbol
> tables are involved. The latter is somewhat mitigated by the new
> symbol table hashing we implemented some time back but still.
About 10% to 50% of the time on i686, this benefit of prelink is trashed
by the randomization of the placement of [vdso], also known as linux-gate.so.
If the page that the kernel chooses for [vdso] overlaps any pre-linked
needed shared library, then ld-linux cannot avoid processing the relocations
for that library. Often the cost snowballs as libraries that do not get
their pre-linked pages are moved so that they interfere with subsequent libraries.
[On x86_64 the vdso is at a special fixed address that cannot conflict.]
Try this example from https://bugzilla.redhat.com/show_bug.cgi?id=162797
-----
for i in 0 1 2 3 4 5 6 7 8 9; do
for j in 0 1 2 3 4 5 6 7 8 9; do
for k in 0 1 2 3 4 5 6 7 8 9; do
ldd /bin/cat
done
done
done | grep libc | sort | uniq -c
-----
For current Fedora 11 on i686, I see a conflict about 10% of the time,
involving only ld-linux, libc, and [vdso]. This means that glibc
must be dynamically relocated about 10% of the time anyway,
even though glibc has been pre-linked, and even though /bin/cat is
near minimal in its use of shared libraries. When a GNOME app uses
50 or more pre-linked shared libs, as claimed in another thread on
this subject, then runtime conflict and expense are even more likely.
If time performance matters a lot, then the kernel must co-operate
when placing the vdso. A patch to FC5 was submitted and adopted
some years ago to offer the choice of: no vdso, random vdso, vdso
just below STACKTOP, vdso just below PT_INTERP (namely, ld-linux.so.2),
vdso just below main. Maintenance suffered because exec_shield was
not in the kernel mainline. None of the choices is available today.
Even the remaining comment in Fedora's kernel/sysctl.c [just after
"int exec_shield = (1<<0);"] is incorrect.
--
More information about the fedora-devel-list
mailing list