[fedora-arm] Include prelink in fedora arm?

[omalleys at msu.edu]

The first version of prelink in MacOS X took 3-4 hours to run after an  
install or major update. I assume this prelink is unrelated to the  
prelink OS X uses, even though IIRC it is opensource?

The difference is instead of touting an up to 3200% performance  
improvement, you are touting an up to 10% performance improvement,  
which would be kickbutt with 4 megs of ram, and a 33mhz processor. And  
could be an extremely useful piece of software if used the correct way.

But as it stands there is very little benefit unless you can make the  
buildbots go 10% faster since the one of the challenges this group  
faces is to get everything compiled once. (which is a major  
accomplishment and there has been extremely good progress.)

There are still 1047 broken dependencies for the armv5tel 14 release  
according to the daily update and the kernel still needs some cleanup  
work.

If you would like to lend a hand or hardware, it would be welcome.

Auto-optimisation from gcc or llvm for simd enhancements could also  
enhance the chances of welcoming prelinking something like an  
armv5/armv7/armv7+neon fat binary. But we are a ways off from doing  
anything remotely resembling that.

Im not trying to cut down the effort, it can be -extremely- useful as  
Apple has demonstrated.  However with 1047 broken dependencies,  
introduction of something else that could introduce errors and cause  
issues is probably not a wise decision for the overall goals of the  
projects at this point especially with literally nothing to gain. Big  
bloated applications have the most to gain which I believe almost all  
of them at this point still have broken dependencies.

I'm not even sure what is gained on the x86 side at this point besides  
a faster boot and maybe a faster launch for gui apps? Which if you use  
btrfs as the default filesystem, boot time is about 2x faster then  
ext4 and if you can actually use video acceleration in gnome, it is  
orders of magnitudes faster so 10% is a small number. But given I have  
to use runlevel3 on F16alpha since it broke after an update with no  
video acceleration, and manually use startx. And grub2 isn't being  
used for EFI support yet, and systemd is still a bit touchy. Im  
thinking there are bigger issues to fix. Prelinking maybe the root  
cause of the corruption of my btrfs filesystem since it took forever  
to shutdown after an update and I finally just powered off since I had  
to go and there is no fsck.btrfs to help recover from failed inodes,  
and gcc wasn't able to install and gnome wasn't acting correctly either.

Just something to think about.


Quoting Jan Kratochvil <jan.kratochvil at redhat.com>:

> On Thu, 08 Sep 2011 11:28:52 +0200, Gordan Bobic wrote:
>> On Wed, 7 Sep 2011 18:09:34 +0200, Jan Kratochvil >   
>> <jan.kratochvil at redhat.com> wrote:
>> > No.  Please read /etc/sysconfig/prelink and
>> > PRELINK_FULL_TIME_INTERVAL, only
>> > once per two weeks.
>>
>>  I meant every time prelink is run, not every time the binary is run.
>
> There is some misunderstanding here.  prelink is run daily and it only
> prelinks newly installed/upgraded executables, it does not touch already
> prelinked executables.  Once per two weeks it re-prelinks everything.
>
> So if your concerns are about changed executables content (for flash wear
> leveling?) that happens at most once per two weeks.  I believe this is
> negligible change compared to other /var files changing all the time.
>
>
>>  You are missing the main point - how much extra CPU and disk I/O is
>>  that going to take during the backup?
>
> Less than all the runtime relocations when executing the programs all the
> time.
>
>
> Please keep at the facts and not trying to find any possible reason why to
> avoid prelink.
>
> prelink is expected even in the original ELF specification, before any such
> program ever existed, as it is the only logical way how to execute ELF files.
>
>
> Thanks,
> Jan
> _______________________________________________
> arm mailing list
> arm at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/arm
>



-- 
"The information in this email, and attachment(s) thereto, is strictly  
confidential and may be legally privileged. It is intended solely for  
the named recipient(s), and access to this e-mail, or any  
attachment(s) thereto, by anyone else is unauthorized. Violations  
hereof may result in legal actions. Any attachment(s) to this e-mail  
have been checked for viruses, but please rely on your own  
virus-checker and procedures. If you contact us by e-mail, we will  
store your name and address to facilitate communications in the matter  
concerned. If you do not consent to us storing your name and address  
for above stated purpose, please notify the sender promptly. Also, if  
you are not the intended recipient please inform the sender by  
replying to this transmission, and delete the e-mail, its  
attachment(s), and any copies of it without, disclosing it."