On 09/07/2011 01:48 AM, Martin Dengler wrote:
On Tue, Sep 06, 2011 at 07:54:17PM +0100, Gordan Bobic wrote:
> On 09/06/2011 06:53 PM, Mark Wielaard wrote:
>> On Tue, Sep 06, 2011 at 07:22:37PM +0200, Jan Kratochvil wrote:
>>> On Tue, 06 Sep 2011 19:15:45 +0200, Kevin Fenzi wrote:
>>>> Personally, I would consider prelink a 'ok, we have everything
working
>>>> now, and we want to look at making it faster' instead of enabling it
>>>> before everything is working or building.
>>>
>>> I agree That makes sense (although I do not think the prelink issues will be
>>> ARM specific and they are already resolved on other arches; I may be wrong).
>>
>> There could be ARM specific bugs. [...] having the prelink
>> package available on ARM would at least help us all test and make
>> sure prelink works as intended. So please do include the package,
>> if only so people can do some measurements to check whether the
>> startup speedup is "just" 10% or even up to 50% on their machines.
>
> I agree on the dependency and testing part, but I think 10% is
> optimistic.
I will soon have a few different ARM machines that I can do testing
on. Please let us know[1] your test suite if you want me to try to
substantiate your pessimism.
Here is the best reason I've heard for prelink on today's standard,
memory-constrained ARM device:
http://lists.laptop.org/pipermail/devel/2011-May/032011.html
Please keep at least the option to enable prelinking in Fedora,
especially before anyone has any performance numbers.
> Gordan
Martin
1. A wiki page about prelink on ARM would probably be even better than
a mailing list post. I will start one if nobody beats me to it.
I ran a little experiment with and without prelink using ps_mem.py from
http://www.pixelbeat.org/scripts/ps_mem.py
I booted up the fc13 arm machine and logged in with two terminal windows up and ran
ps_mem.py saving the result into a file. The no_prelink_mem.log is the output without
prelink and prelink_mem.log is the output after a prelink and reboot. Savings is about
2.7% (107.6MB vs 110.6MB) of the RAM in this trivial case. Generally, see the amount of
private memory required for individual executables reduced for the prelinked versions.
There were a some that had higher private memory use (bluetoothd, dbus-daemon, and udevd),
but that might be more of a result of the quick and dirty benchmarking.
-Will
-Will