[fedora-arm] Include prelink in fedora arm?
omalleys at msu.edu
omalleys at msu.edu
Thu Sep 8 18:55:25 UTC 2011
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
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
> 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.
> arm mailing list
> arm at lists.fedoraproject.org
"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."
More information about the arm