prelink: is it worth it?

[Jakub Jelinek]

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