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.
-Jon
On Tue, Sep 6, 2011 at 12:14 PM, Gordan Bobic <gordan@xxxxxxxxxx> wrote:
On Tue, 6 Sep 2011 19:01:57 +0200, Jan KratochvilI did, and found no definitive, reproducible results to support the 50%
<jan.kratochvil@xxxxxxxxxx> 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).
claim. It certainly wasn't corroborated by my own measurements - last
time I tested what benefit it gives, the results were at best
inconclusive.
The only performance claims that are worth listening to are the ones
> 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.
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.
If we're going to argue the performance toss, rewriting yum in C would
> 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.
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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/arm
-Jon
_______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
