On Tue, 2011-09-13 at 08:51:17 +0200, Raphael Hertzog wrote: > On Tue, 13 Sep 2011, Guillem Jover wrote: > > I installed iceweasel on an ARM system (Thecus N2100), w/o X forwarding, > > and no user profile, so it just stops when it's not able to find the > > DISPLAY, but that should be good enough to get timings close to just the > > startup relocation times, which is what the ld.so stats show on amd64 > > for example. Caches flushed on each iteration, which were pretty > > consistent, I've included two different ones for each: > > I did the same on my eSATA SheevaPlug (armel too) and I don't get the same > results than you.
[SheevaPlug tests] > > As it can bee seen the difference is pretty significant. > > As it can be seen, the difference is not something that affects > all armel machines in the same way. > > I did 10 run of each, dropped the biggest value and did the mean > value on the rest: > - bind lazy: 1.842s > - bind now: 1.910s > > Difference: +3,6 % Well an eSATA SheevaPlug is a pretty fast ARM machine! In any case it was not my intention to imply all ARM machines would be affected equally. I said the impact would be more noticable on slow architectures, which ARM tends to be. In this case I/O is most probably the culprit, something I hinted at on my first mail on this sub-thread. And this will affect any system with slow I/O. > > > Feel free to change it if you think it's better that way. I'm not attached > > > to it. > > > > I'm changing it now on my local tree, will be included in my next > > push. I took the commit out from my push because this was still under discussion, that does not mean I've changed my mind though and I still do not really feel comfortable uploading a dpkg defaulting to bind now. > Given my test, I'm not convinced it's the right course of action. > > I did the same test on my i386 setup and I got this: > - bind lazy: 0.320s > - bind now: 0.330s > > Difference: +3,1 % > > At the very least, we could keep it enabled for i386/amd64, no ? I've written some of this in some previous mail, but I'll repeat. This can have real impact on performance, it potentially affects the whole archive (once it all switches to using dpkg-buildflags), and even on overally fast archiectures it might still affect a range of its slow systems, once bind now is set on an object (via DF_1_NOW, DF_BIND_NOW or DT_BIND_NOW) it cannot be disabled by neither of dlopen(RTLD_LAZY) nor environment variables, it's trading an optimization with a security measure. So given its obvious drawbacks (something the other options do not seem to present), that we can always change it in the future, I don't think the current default should be changed. In this kind of case our stance should really be “if in doubt, do not change”. But if this was to get changed, this is something the project at large should get consensus on, not just the dpkg team. Of course specific maintainers are free to choose compilation options for their own packages, because that does (generally) have a global impact, and they can assess what side of the trade off is more important. regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110920023705.ga19...@gaara.hadrons.org
