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