Fixed memory address

[Bernardo Innocenti]

Chris Ball wrote:

>    > I think we could run prelink on the OLPC images from within
>    > pilgrim, just before converting it to jffs2.
> 
>    > It will result in a slight speedup in startup time, but nothing
>    > compared to importing modules that dominates startup time of the
>    > Python activities.
> 
> Actually, I did exactly this:
> 
> # prelink -avm /
> # reboot
> 
> And it made no discernible difference (with a stopwatch) to boot time,
> activity startup time, or activity memory use.  It was pretty confusing.
> If someone wants to see if they can have better luck with it, that'd be
> fine with me.

If it made no change at all to the split second, then I guess the binaries
were already prelinked or prelinking is failing for some reason.

I said *slight* speedup because I knew it wouldn't matter that much for
the kind of libraries we use.  The speedup is proportional to the number
of relocations done by ld.so, and C binaries don't do that many.

There used to be some O(2) behavior in ld.so, but I think Jakub optimzed
it to be O(N*log(N)) some time ago, and later on Fedora switched to use
the gnu.hash ELF extension to mitigate the problem even further.

So my guess is that prelinking might still be beneficial, but the effect
is mostly visible for degenerate cases such as Qt/KDE libraries, which
have hundreds of classes, each with a huge vtable containing pointers to
member functions which have to be relocated even if not used.

There should also be some (minor?) memory savings in using prelink,
because each page containing a relocation has to be copied per-process.
This is the kind of memory problems that we'd never see without the PSS
and USS kernel patches, because the VMM and RSS of the application
doesn't change when COW occurs!

-- 
 \___/
 |___|  Bernardo Innocenti - http://www.codewiz.org/
  \___\ One Laptop Per Child - http://www.laptop.org/