prelink performance gains

[Reindl Harald]

Am 17.10.2013 15:48, schrieb Jan Kratochvil:
> On Thu, 17 Oct 2013 00:16:35 +0200, Robert Relyea wrote:
>> prelink throws rocks at a lot of packages that have to check the
>> integrity of the shared libraries they are using. It provides no real
>> useful way of assisting in those tasks,
> 
> It provides 'prelink -y' only for exactly that purpose.
> There is a bug in -y; but it does not work in some (rare) cases.
>   https://bugzilla.redhat.com/show_bug.cgi?id=666143
> Workaround of that bug is one line of code, it just has not been accepted yet.
> 
>> and we can't meaningfully
>> measure or observe the performance gains. You will need to strongly show
>> the latter, because the cost it forces on other packages is unbearable.
> 
> Here is another measurement. I do not agree with the initial post's approach
> as (1) It flushes disk cache.  That has no meaning for prelink measurement, it
> just adds more fuzziness to the results and it is even unreal representation
> of real world use cases.  (2) It runs big end-user GUI application.

what is the proposed usecase for prelink all the years

> This adds
> various interactions with X and the applications has its own heavy startup
> cost, it all also adds fuzziness to the results.  (3) When we look at global
> GNU/Linux market its end user deployment (*Office) is not relevant, server
> side execution matters.  => It all seems to me as intentionally chosen just to
> prove prelink gain is not measurable.

you think the startup performance matters on servers?
come on - nobody is starting and stopping servcices all day long

*espcecially* on servers you *do not want* prelink because intrusion
detection and the fact that honestly *all* long running processes aka
services must be PIE and so are not prelined at all

so, and for the ones violating package guidelines because not PIE
you do *not* want prelink because on a server typically you install
updates, restart the service or reboot in rare cases, have no
ASLR and that prelink comes at night for the minimal ASLR does
not help because the binaries are already running

and *no* do *not* propose now restart services blindly after prelink
so what about are you talking in this whole thread?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20131017/9bb2ae8c/attachment.sig>