On Thu, Jul 09, 2009 at 10:32:01AM -0400, Matthew Miller wrote: > Apparently there was some fun with prelink breaking everything in rawhide > recently: <https://bugzilla.redhat.com/show_bug.cgi?id=509655>. I didn't > notice, because like Pete Zaitcev says in the comments, removing prelink is > one of the first things I do. > > I see it as adding unnecessary complexity and fragility, and it makes > forensic verification difficult. Binaries can't be verified without being > modified, which is far from ideal. And the error about dependencies having > changed since prelinking is disturbingly frequent. > > On the other hand, smart people have worked on it. It's very likely that > those smart people know things I don't. I can't find any good numbers > anywhere demonstrating the concrete benefits provided by prelink. Is there > data out there? Pretty charts and graphs would be nice. The only things I've > been able to find are old and not very impressive: > > <http://crast.us/james/articles/prelink.php> > <http://smackerelofopinion.blogspot.com/2009/06/does-prelinking-speed-up-boot-times.html> > <http://reallylongword.org/prelink-2/> Say on x86-64 F11 (with /etc/prelink.conf.d/nss-prelink.conf removed): LD_DEBUG=statistics /usr/lib64/openoffice.org3/program/swriter.bin 11799: 11799: runtime linker statistics: 11799: total startup time in dynamic loader: 18632372 clock cycles 11799: time needed for relocation: 2975643 clock cycles (15.9%) 11799: number of relocations: 0 11799: number of relocations from cache: 1527 11799: number of relative relocations: 0 11799: time needed to load objects: 13190177 clock cycles (70.7%) LD_USE_LOAD_BIAS=0 LD_DEBUG=statistics /usr/lib64/openoffice.org3/program/swriter.bin 11817: 11817: runtime linker statistics: 11817: total startup time in dynamic loader: 145813250 clock cycles 11817: time needed for relocation: 129375884 clock cycles (88.7%) 11817: number of relocations: 42207 11817: number of relocations from cache: 126013 11817: number of relative relocations: 149959 11817: time needed to load objects: 15248893 clock cycles (10.4%) The former is how long it takes before swriter.bin starts up when prelinked, the latter tells it not to use prelink information and do normal relocation. Try this on any other GUI app that links against dozens of shared libraries. Even on binaries that link against only very few libraries, but are executed often it makes a difference, say consider configure scripts or libtool that exec hundreds to thousands small programs. And time isn't the only saving, another is that fewer pages are dirtied. The rawhide prelink issue is just that we've added a new ELF extension to the toolchain (binutils, glibc) and prelink had to be changed to handle it. Jakub -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
