Re: Prelink problems -- need help!

[Mark Hatle <mark.hatle@windriver.com>]

On 10/29/15 1:32 PM, Khem Raj wrote:
> 
>> On Oct 26, 2015, at 9:55 AM, Mark Hatle <mark.hatle@windriver.com> wrote:
>>
>> On 10/26/15 11:50 AM, Phil Blundell wrote:
>>> On Mon, 2015-10-26 at 11:45 -0500, Mark Hatle wrote:
>>>>
>>>>
>>>> While some of the modern hashing techniques and such do improve run
>>>> -time dynamic
>>>> link performance, there is still a hit that we must take.  For
>>>> devices that need
>>>> quick boot times, quick startup, or are memory constrained, the
>>>> prelinker can
>>>> still help.  (Memory usage on very small systems is a good example.
>>>> Memory
>>>> usage can be reduced in larger applications by reducing the number of
>>>> Copy-on-write pages required to handle the relocation information.)
>>>
>>> Do you have any concrete data on how much of a boot time speedup,
>>> and/or what reduction in dirty pages, you see on a modern image with
>>> prelink versus the same image without?
>>
>> -last- time I got concrete numbers on a complex boot process.  It was on the
>> order of 1-5% boot time.. and a fairly large number of pages saved.. (which
>> reduced fragmentation as well as saved memory.)
> 
> How is fragmentation getting better ? if dynamic linker was improving the page
> locality then it would be possible but that does not seem to be the case here.

With no relocations, you don't end up doing COW pages.  No COW pages means less
memory used for running many of the small quick Linux scripts at easy boot.

These are issues I've seen on older slower systems.  It's not that big of a deal
with a lot of the newer ones.

However, someone pointed out to me earlier today that with more and more IFUNCs
being used across different platforms, that it's likely the COW page savings are
reduced from what they used to be....  If the IFUNCs are 'local to the same
page', then it should still help reduce the overall count...  but I'm not sure
that is something that is controlled in the normal case.

--Mark

>>
>> We're not talking huge numbers for each, there is a statistics mode in glibc
>> that can be enabled to show the number of relocations and some of the costs
>> involved.  Once this is working again, I will be able to run that and give more
>> concrete numbers.
>>
>> --Mark
>>
>>> p.
>>>
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>