Re: prelink: is it worth it?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> [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.

-- 

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux