[fedora-arm] Include prelink in fedora arm?

Jon jdisnard at gmail.com
Tue Sep 6 17:28:56 UTC 2011

We like randomized addresses, improves security so exploit code cannot
anticipate the address.
Prelinked address might improve startup speed, but I'm not convinced the
speedup is worth the risk.
I believe even when sysctl is set to randomize address space, prelink will
still effect normalized addresses.

Also, there are questions about the actual speedup.

I feel prelink should be disabled in fedora completely.

However, updating the package is still desirable for resolving dependencies.


On Tue, Sep 6, 2011 at 12:14 PM, Gordan Bobic <gordan at bobich.net> wrote:

>  On Tue, 6 Sep 2011 19:01:57 +0200, Jan Kratochvil
>  <jan.kratochvil at redhat.com> wrote:
> > On Tue, 06 Sep 2011 17:39:55 +0200, Gordan Bobic wrote:
> >>  Can you elaborate as to why? My experience and measurements show
> >> that
> >>  prelink does more harm than good more offten than not. I can think
> >> of a
> >>  lot of reasons to not use it, and very few reasons to use it.
> >
> > It speeds up the program startup up to 50% (you can Google out
> > various
> > benchmarks).
>  I did, and found no definitive, reproducible results to support the 50%
>  claim. It certainly wasn't corroborated by my own measurements - last
>  time I tested what benefit it gives, the results were at best
>  inconclusive.
> > As almost any performance feature it sure comes with more
> > complexity of the ELF files handling.  The most easy ELF files
> > processing
> > would be with -O0 code - so why do we build the programs with -O2?
> >
> > Nowadays some people do not consider performance as anything to care
> > about so
> > in such case it is understandable they do not see a need for prelink.
>  The only performance claims that are worth listening to are the ones
>  supported by evidence showing consistent and reproducible improvement -
>  and I have seen no such thing to support prelink recently.
>  And I just thought of another reason to not use prelink, in addition to
>  tripwire/IDS issues and vserver's hashify feature - flash media.
>  Rewriting a large chunk of your binaries on a semi-regular basis isn't
>  going to help the longevity of a system running off cheap flash media,
>  as most ARMs are doing.
> > It is true that if program is written in C it is usually fast enough.
> > But specifically ARM may be the only popoular platform where I do not
> > find the C programs fast enough, though.
>  If we're going to argue the performance toss, rewriting yum in C would
>  be a good start toward addressing the eyewateringly big performance
>  issues. Compared to that, anything that prelink could possibly achieve
>  gets lost in the noise.
>  To summarize - I'm unconvinced of the benefits of prelink. But I will
>  happily be persuaded otherwise by reasonably broad and repeatable
>  empirical evidence.
>  Gordan
> _______________________________________________
> arm mailing list
> arm at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/arm


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/arm/attachments/20110906/610bfa86/attachment.html 

More information about the arm mailing list