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. 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. Therefore I made IMO a more real world measurement with: time gdb/configure Particularly: for i in `seq 1 20`;do git clean -dfx &>/dev/null;sync;sleep 6;(time ./configure &>/dev/null) 2>&1|grep ^real|tee -a /tmp/times;done To make clear why such test matters. Running configure scripts has become the major builds bottleneck in recent days as it cannot be parallelized on multicore and multinode machines. For GDB it takes now 56% (of 1m37.380s) of the whole compilation time. And be sure developers are running configure by orders of magnitude more times than *Office (or even LaTeX). without prelink (in seconds): 54.832 54.099 55.122 54.704 54.228 54.728 54.240 53.914 54.878 54.308 54.461 53.859 54.311 53.964 53.958 54.712 54.498 53.924 54.988 54.502 mean 54.4115 | standard deviation 0.39093 with prelink (in seconds): 53.392 52.569 52.549 53.005 52.452 52.719 53.278 52.534 52.439 52.737 52.571 52.656 53.142 52.671 52.555 52.973 52.483 52.369 53.246 53.128 mean 52.7734 | standard deviation 0.31998 mean gain 1.6381 == 3.01% Unfortunately I have to admit that does not mean much. According to Observer Effect and Measurement Bias in Performance Analysis http://www.inf.usi.ch/faculty/hauswirth/publications/CU-CS-1042-08.pdf completely unrelated environment conditions (like object files reorder) cause up to 5% performance measurement bias; please read the PDF for the reasons. > >> - FIPS foot-bullets [..] > 1. Some packages supports FIPS on the fly. I do not know the FIPS prelink issues to be able to talk more about it. > 2. FIPS isn't the only place you need to do sofware integrity checks. > (see rpm). rpm uses prelink -y so it already works in most cases and the rare cases can be fixed in prelink. The problem is its maintainer Jakub has more significant work to do nowadays. > If prelink provided noticeable improvement, It depends whether 3% (of configure time); or rather 1.69% of total build time matters or not. If it is relevant for example more expensive i7-4771 is just 3% faster than i7-4770. > I would say we put the resources into prelink to make it play more nicely > with these integrity systems, but since it doesn't, the more rational > approach is have it go away. According to the numbers above my conclusion is different. I agree there remains some work on prelink itself and some packages around to make prelink relevant again for the predominant notebook market nowadays. prelink performance gains [summary] https://lists.fedoraproject.org/pipermail/devel/2013-October/190309.html Thanks, Jan -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
