prelink: is it worth it?
yersinia
yersinia.spiros at gmail.com
Thu Jul 9 15:07:05 UTC 2009
On Thu, Jul 9, 2009 at 4:55 PM, Ulrich Drepper <drepper at redhat.com> wrote:
> Adam Miller wrote:
> > I am curious as to this answer as well because prelink has been
> > something that actually hurt my netbook in performance so I nuked it.
>
> Performance only ever can be hurt because prelink runs periodically to
> prelink newly installed code or re-randomize to increase security.
>
> prelink has two benefits:
>
> - 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.
>
> - as a side effect of the first point some pages in the loaded binary
> are not copied-on-write. This can obviously have good effects on
> systems with little memory (netbooks).
>
>
> Just run your own tests on apps with many relocations and dependencies.
> FF, OO.org, most GUI apps come into mind. Use
>
> LD_DEBUG=statistics some/program
>
> to compare numbers. Run it with and without prelink (but always with
> hot disk cache to be fair). The number of cycles for total startup is
> representative of the win.
>
> Note, also small but frequently used apps benefit. I run gcc etc a lot
> and like every single saved cycle.
>
But something one have to pay a security prize on not disabling it : it
render impossible to have a
centralizzated security integrity management (e.g. rfc.sf.net for example)
or one have to skip from check the prelink binary. Very bad i think.
>
> --
> ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
>
> --
> fedora-devel-list mailing list
> fedora-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20090709/9cc47287/attachment.htm>
More information about the fedora-devel-list
mailing list