On Tuesday, 16 de August de 2011 12:50:47 Laszlo Papp wrote: > Hi, > > > kdeinit can be replaced by prelinking, assuming you are not a user of the > > NVidia binary drivers. If you are, you can't prelink, so kdeinit is a > > help: > > > > /usr/sbin/prelink: /usr/bin/gears: Cannot prelink against non-PIC shared > > library /usr/lib/nvidia-current/libGL.so.1 > > The nvidia driver does a lot of tricks and libGL is not a PIC library, > but that does not matter. My understanding was that kdeinit cannot be > replaced by prelinking in any case since they are two different > things.
They are different things, but in the end they are trying to solve the same problem: slowness at startup due to the loading of libraries and the processing of their relocations, plus sharing the otherwise non-sharable memory resulting from it. Unfortunately, comparing the results of the best that prelink can do (prelinked system, libs compiled with -Wl,-z,relro) and kdeinit, done by launching kwrite twice from the command-line and twice using kdeinit4_wrapper, I still see that kdeinit produces better results. My findings are: 1) the kdeinit executable is far larger in VSZ and just a bit larger in RSS (that's expected and is not a problem) 2) the kdeinit instance shares 32120 kB, whereas the non-kdeinit one shares 28536 kB. Again, no conclusion from here (the kdeinit instance is sharing memory that it won't need). 3) the kdeinit instance has 10120 kB non-shared, whereas the non-kdeinit one has 10296 kB. If we take away the heap and stack, we get the breakdown: kdeinit: 88 kB code, 244 kB RO data, 376 kB RW data non-kdeinit: 0 kB code, 620 kB RO data, 992 kB RW data All of the memory above is dirty, meaning in principle that it's non-sharable. That includes the 88 kB of code, which makes no sense at all to me. I'm guessing it's an effect of the prelinking, but still at loss to explain. Also note that those RO pages, due to the way that the loader and the linker work, do *not* include the .rodata sections. They are only the "relro" data -- that is, read-only data that requires relocations. > In harmattan the preloader is called booster, and it basically does a > dlopen() on important libraries and we also use prelinking. They live > together. I think prelink and kdeinit could work together, but please > fix me. Prelink or cross-prelink could just be used by the > distributions (but it should be done after install, just like debian > does, prelink is setup in cron) to make it clear. :) The booster also dlopens the plugins, I think, which further improves performance. The prelinker does not properly prelink plugins, since it doesn't know what uses them. That means a set of applications heavily dependent on plugins, like the Qt- and KDE-based apps, will still not be at ideal conditions with the prelinker. A workaround is to create a dummy binary or library that links to the plugins (violation of the definition, I know), so that the prelinker knows that it should work on them. > Unfortunately I missed this session because of the football match. I > think kdeinit is a nice thing over there. PIE executables had some > different purpose, mostly security related. For some reason, some > people started abusing them. There was an article by Jakub explaining > this. I can not seem to find it right now. In any case, the main > advantage of PIE executables was that the executable address space > could be randomized, and ldconfig does randomize the address. > Basically, this makes buffer-overruns more difficult. One thing is > that ld.so ignores prelink information for PIE executables. Other than > this I really see no point in them Another advantage of PIE is that the executable itself is position- independent, meaning that the code can be shared if more than one instance is loaded. For single-instance applications, this is not a gain. The disadvantage of PIE is the same of any position-independent code: one register is reserved (big problem on a register-starved CPU like the x86), data accesses are indirect, via the GOT, and function calls are also indirect via the PLT. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.