Would it be possible to get the new prelink rpm pulled into arm builds?
The prelink arm support (rhbz#733089) is available in:
http://koji.fedoraproject.org/koji/buildinfo?buildID=260584
-Will
On Tue, 06 Sep 2011 11:34:43 -0400, William Cohen wcohen@redhat.com wrote:
Would it be possible to get the new prelink rpm pulled into arm builds?
The prelink arm support (rhbz#733089) is available in:
Can you elaborate as to why? My experience and measurements show that prelink does more harm than good more offten than not. I can think of a lot of reasons to not use it, and very few reasons to use it.
Gordan
On Tue, Sep 6, 2011 at 12:39 PM, Gordan Bobic gordan@bobich.net wrote:
On Tue, 06 Sep 2011 11:34:43 -0400, William Cohen wcohen@redhat.com wrote:
Would it be possible to get the new prelink rpm pulled into arm builds?
The prelink arm support (rhbz#733089) is available in:
Can you elaborate as to why? My experience and measurements show that prelink does more harm than good more offten than not. I can think of a lot of reasons to not use it, and very few reasons to use it.
Gordan
alot of programs use it, rpmfusion programs are examples.
On Tue, 6 Sep 2011 13:41:22 -0300, Itamar Reis Peixoto itamar@ispbrasil.com.br wrote:
On Tue, Sep 6, 2011 at 12:39 PM, Gordan Bobic gordan@bobich.net wrote:
On Tue, 06 Sep 2011 11:34:43 -0400, William Cohen wcohen@redhat.com wrote:
Would it be possible to get the new prelink rpm pulled into arm builds?
The prelink arm support (rhbz#733089) is available in:
Can you elaborate as to why? My experience and measurements show that prelink does more harm than good more offten than not. I can think of a lot of reasons to not use it, and very few reasons to use it.
alot of programs use it, rpmfusion programs are examples.
Can you list them? In the RHEL6 distro I only see it being required by aide and hmaccalc (I may be missing a few, my logs aren't quite complete).
Gordan
AIDE is one good example of software that is hurt by prelink.
The prelinking feature can interfere with AIDE because it changes binaries in an attempt to decrease startup time. In other words prelink causes false positives.
So I'm surprised to read that in rhel6 prelink is required by aide.
Regardless, I suppose having the latest version is desirable for those looking to speed startup times. Or perhaps just compile dependencies.
-Jon
On Tue, Sep 6, 2011 at 11:46 AM, Gordan Bobic gordan@bobich.net wrote:
On Tue, 6 Sep 2011 13:41:22 -0300, Itamar Reis Peixoto itamar@ispbrasil.com.br wrote:
On Tue, Sep 6, 2011 at 12:39 PM, Gordan Bobic gordan@bobich.net wrote:
On Tue, 06 Sep 2011 11:34:43 -0400, William Cohen wcohen@redhat.com wrote:
Would it be possible to get the new prelink rpm pulled into arm builds?
The prelink arm support (rhbz#733089) is available in:
Can you elaborate as to why? My experience and measurements show that prelink does more harm than good more offten than not. I can think of a lot of reasons to not use it, and very few reasons to use it.
alot of programs use it, rpmfusion programs are examples.
Can you list them? In the RHEL6 distro I only see it being required by aide and hmaccalc (I may be missing a few, my logs aren't quite complete).
Gordan _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On Tue, 6 Sep 2011 12:01:34 -0500, Jon jdisnard@gmail.com wrote:
AIDE is one good example of software that is hurt by prelink.
The prelinking feature can interfere with AIDE because it changes binaries in an attempt to decrease startup time. In other words prelink causes false positives.
So I'm surprised to read that in rhel6 prelink is required by aide.
Regardless, I suppose having the latest version is desirable for those looking to speed startup times. Or perhaps just compile dependencies.
Compiling dependencies I can understand, but I am not at all convinced about the start-up time benefits. I haven't seen any conclusive, objective and consistent evidence of it yet, and I can think of a lot of reasons to avoid prelink (tripwire and vserver hashify are two things that immediately come to mind).
Gordan
On Tue, 06 Sep 2011 19:06:13 +0200, Gordan Bobic wrote:
I can think of a lot of reasons to avoid prelink (tripwire and vserver hashify are two things that immediately come to mind).
Any programs verifying executables should run prelink -y (or -u) on the executable to restore its original state first.
It is a bug of those programs tripwire and vserver which should be fixed.
Thanks, Jan
On 09/06/2011 06:24 PM, Jan Kratochvil wrote:
On Tue, 06 Sep 2011 19:06:13 +0200, Gordan Bobic wrote:
I can think of a lot of reasons to avoid prelink (tripwire and vserver hashify are two things that immediately come to mind).
Any programs verifying executables should run prelink -y (or -u) on the executable to restore its original state first.
It is a bug of those programs tripwire and vserver which should be fixed.
I beg to differ. But regardless, care to add up what that will do to the life expectancy of your built in flash that the OS runs from on any of the commonly used ARM devices (SheevaPlug, AC100, Genesi Efika)?
Gordan
On Tue, 06 Sep 2011 17:39:55 +0200, Gordan Bobic wrote:
Can you elaborate as to why? My experience and measurements show that prelink does more harm than good more offten than not. I can think of a lot of reasons to not use it, and very few reasons to use it.
It speeds up the program startup up to 50% (you can Google out various benchmarks). As almost any performance feature it sure comes with more complexity of the ELF files handling. The most easy ELF files processing would be with -O0 code - so why do we build the programs with -O2?
Nowadays some people do not consider performance as anything to care about so in such case it is understandable they do not see a need for prelink.
It is true that if program is written in C it is usually fast enough. But specifically ARM may be the only popoular platform where I do not find the C programs fast enough, though.
Regards, Jan
On Tue, 6 Sep 2011 19:01:57 +0200, Jan Kratochvil jan.kratochvil@redhat.com wrote:
On Tue, 06 Sep 2011 17:39:55 +0200, Gordan Bobic wrote:
Can you elaborate as to why? My experience and measurements show that prelink does more harm than good more offten than not. I can think of a lot of reasons to not use it, and very few reasons to use it.
It speeds up the program startup up to 50% (you can Google out various benchmarks).
I did, and found no definitive, reproducible results to support the 50% claim. It certainly wasn't corroborated by my own measurements - last time I tested what benefit it gives, the results were at best inconclusive.
As almost any performance feature it sure comes with more complexity of the ELF files handling. The most easy ELF files processing would be with -O0 code - so why do we build the programs with -O2?
Nowadays some people do not consider performance as anything to care about so in such case it is understandable they do not see a need for prelink.
The only performance claims that are worth listening to are the ones supported by evidence showing consistent and reproducible improvement - and I have seen no such thing to support prelink recently.
And I just thought of another reason to not use prelink, in addition to tripwire/IDS issues and vserver's hashify feature - flash media. Rewriting a large chunk of your binaries on a semi-regular basis isn't going to help the longevity of a system running off cheap flash media, as most ARMs are doing.
It is true that if program is written in C it is usually fast enough. But specifically ARM may be the only popoular platform where I do not find the C programs fast enough, though.
If we're going to argue the performance toss, rewriting yum in C would be a good start toward addressing the eyewateringly big performance issues. Compared to that, anything that prelink could possibly achieve gets lost in the noise.
To summarize - I'm unconvinced of the benefits of prelink. But I will happily be persuaded otherwise by reasonably broad and repeatable empirical evidence.
Gordan
We like randomized addresses, improves security so exploit code cannot anticipate the address. Prelinked address might improve startup speed, but I'm not convinced the speedup is worth the risk. I believe even when sysctl is set to randomize address space, prelink will still effect normalized addresses.
Also, there are questions about the actual speedup.
I feel prelink should be disabled in fedora completely.
However, updating the package is still desirable for resolving dependencies.
-Jon
On Tue, Sep 6, 2011 at 12:14 PM, Gordan Bobic gordan@bobich.net wrote:
On Tue, 6 Sep 2011 19:01:57 +0200, Jan Kratochvil jan.kratochvil@redhat.com wrote:
On Tue, 06 Sep 2011 17:39:55 +0200, Gordan Bobic wrote:
Can you elaborate as to why? My experience and measurements show that prelink does more harm than good more offten than not. I can think of a lot of reasons to not use it, and very few reasons to use it.
It speeds up the program startup up to 50% (you can Google out various benchmarks).
I did, and found no definitive, reproducible results to support the 50% claim. It certainly wasn't corroborated by my own measurements - last time I tested what benefit it gives, the results were at best inconclusive.
As almost any performance feature it sure comes with more complexity of the ELF files handling. The most easy ELF files processing would be with -O0 code - so why do we build the programs with -O2?
Nowadays some people do not consider performance as anything to care about so in such case it is understandable they do not see a need for prelink.
The only performance claims that are worth listening to are the ones supported by evidence showing consistent and reproducible improvement - and I have seen no such thing to support prelink recently.
And I just thought of another reason to not use prelink, in addition to tripwire/IDS issues and vserver's hashify feature - flash media. Rewriting a large chunk of your binaries on a semi-regular basis isn't going to help the longevity of a system running off cheap flash media, as most ARMs are doing.
It is true that if program is written in C it is usually fast enough. But specifically ARM may be the only popoular platform where I do not find the C programs fast enough, though.
If we're going to argue the performance toss, rewriting yum in C would be a good start toward addressing the eyewateringly big performance issues. Compared to that, anything that prelink could possibly achieve gets lost in the noise.
To summarize - I'm unconvinced of the benefits of prelink. But I will happily be persuaded otherwise by reasonably broad and repeatable empirical evidence.
Gordan _______________________________________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On Tue, 06 Sep 2011 19:28:56 +0200, Jon wrote:
We like randomized addresses, improves security so exploit code cannot anticipate the address. Prelinked address might improve startup speed, but I'm not convinced the speedup is worth the risk.
Executables where any such randomization can bring security benefits are already built as PIE and prelink has no effect on such executables.
There has never been made any security compromise for prelink.
I feel prelink should be disabled in fedora completely.
Are you going to also ask for -O0 compilation for better debuggability with debuginfo rpms?
Thanks, Jan
On 09/06/2011 06:42 PM, Jan Kratochvil wrote:
On Tue, 06 Sep 2011 19:28:56 +0200, Jon wrote:
We like randomized addresses, improves security so exploit code cannot anticipate the address. Prelinked address might improve startup speed, but I'm not convinced the speedup is worth the risk.
Executables where any such randomization can bring security benefits are already built as PIE and prelink has no effect on such executables.
There has never been made any security compromise for prelink.
I feel prelink should be disabled in fedora completely.
Are you going to also ask for -O0 compilation for better debuggability with debuginfo rpms?
Packages that break with -On where n > 0, already get build with -O0 - package maintainers see to that. The point is that prelink can and does break other things, and in the case of vserver hashify it will actually cause the memory pressure to be multiplied by a potentially very large factor, thus killing performance.
And the issue of the meaningful, measurable and consistent benefit still hasn't been cleared up.
Gordan
On 09/06/2011 06:28 PM, Jon wrote:
We like randomized addresses, improves security so exploit code cannot anticipate the address. Prelinked address might improve startup speed, but I'm not convinced the speedup is worth the risk. I believe even when sysctl is set to randomize address space, prelink will still effect normalized addresses.
Also, there are questions about the actual speedup.
I feel prelink should be disabled in fedora completely.
Agreed. Also if I am not very much mistaken, most other distros do exactly that - disable prelink by default.
However, updating the package is still desirable for resolving dependencies.
Indeed, that is livable with.
Gordan
On 09/06/2011 01:14 PM, Gordan Bobic wrote:
To summarize - I'm unconvinced of the benefits of prelink. But I will happily be persuaded otherwise by reasonably broad and repeatable empirical evidence.
Gordan
Hi Gordan,
What were the benchmarks you used to gauge the performance of prelink? Also what was the environment used? Maybe slow I/O rather than slow relocations dominated the startup time.
-Will
On 09/06/2011 07:24 PM, William Cohen wrote:
On 09/06/2011 01:14 PM, Gordan Bobic wrote:
To summarize - I'm unconvinced of the benefits of prelink. But I will happily be persuaded otherwise by reasonably broad and repeatable empirical evidence.
Gordan
Hi Gordan,
What were the benchmarks you used to gauge the performance of prelink? Also what was the environment used? Maybe slow I/O rather than slow relocations dominated the startup time.
It is plausible that I/O was the bigger bottleneck when I was testing things, but slow I/O is what we have on ARM.
Gordan
On 09/06/2011 08:14 PM, Gordan Bobic wrote:
What were the benchmarks you used to gauge the performance of prelink? Also what was the environment used? Maybe slow I/O rather than slow relocations dominated the startup time.
It is plausible that I/O was the bigger bottleneck when I was testing things, but slow I/O is what we have on ARM.
But surely you'd be looking at CPU time too.
Andrew.
I just thought of another reason to not use prelink - incremental backups. Prelinking will change the binaries every time it is run thus triggering an unnecessarily large backup. Couple that with the fact that it will nullify the advantage gained from de-duplicating storage. For example, my backup solution is lsyncd triggering rsync going to a copyfs backed by zfs with deduplication. Multiply that increase in bandwidth/storage requirements with a potentially large number of machines and the problem becomes non-trivial.
So, to summarize, the list of reasons not to use it thus far: - incremental backups - tripwire-like IDS - increased unnecessary flash wear - renders vserver hashify ineffective
I accept that there may be cases where it is useful in some measure - I just don't think it should be on by default.
Gordan
On 09/07/2011 05:10 AM, Gordan Bobic wrote:
I just thought of another reason to not use prelink - incremental backups. Prelinking will change the binaries every time it is run thus triggering an unnecessarily large backup. Couple that with the fact that it will nullify the advantage gained from de-duplicating storage. For example, my backup solution is lsyncd triggering rsync going to a copyfs backed by zfs with deduplication. Multiply that increase in bandwidth/storage requirements with a potentially large number of machines and the problem becomes non-trivial.
So, to summarize, the list of reasons not to use it thus far:
- incremental backups
- tripwire-like IDS
- increased unnecessary flash wear
- renders vserver hashify ineffective
I accept that there may be cases where it is useful in some measure - I just don't think it should be on by default.
Gordan
Hi Gordan,
In the case of having multiple guest virtual machines on the same physical machine having something like prelink modify the binaries would make it harder to find those identical files. However, in many cases for ARM people are running code on small physical arm machines. Using prelink to make more of the memory read-only could help performance on these small memory machines. It would be nice to have the option of using prelink on ARM in these situations.
How much additional wear to the flash device would running a daily cron job going to add? It isn't modififying a sector hundreds of times a minute continuously.
Is there a lot of rpm changes going on in your environment? /etc/cron.daily/prelink appears to take some measure to minimize the amount of work it does by using quick mode (-q) most of the time.
-Will
On Wed, 07 Sep 2011 11:10:14 +0200, Gordan Bobic wrote:
Prelinking will change the binaries every time it is run
No. Please read /etc/sysconfig/prelink and PRELINK_FULL_TIME_INTERVAL, only once per two weeks.
I just thought of another reason to not use prelink - incremental backups.
[...]
thus triggering an unnecessarily large backup.
This is again a bug in your backup tool. I backup by duplicity with:
# https://bugzilla.redhat.com/show_bug.cgi?id=666143 touch /var/lib/prelink/force && time /etc/cron.daily/prelink time rpm -Vva 2>/dev/null|perl -ne 's/^[.]{7}[.T][.] . // or next;chomp;print "- $_\n" if -f;' >$RPMSAFE [...] --exclude-filelist $RPMSAFE \
So, to summarize, the list of reasons not to use it thus far:
If you have so specific reasons the prelink is not appropriate for you sure feel free to disable it.
For example it was found on LiveCD images the slight increase of the image size is not worth the better runtime performance. https://bugzilla.redhat.com/show_bug.cgi?id=679880
Thanks, Jan
On Wed, 7 Sep 2011 18:09:34 +0200, Jan Kratochvil jan.kratochvil@redhat.com wrote:
On Wed, 07 Sep 2011 11:10:14 +0200, Gordan Bobic wrote:
Prelinking will change the binaries every time it is run
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.
I just thought of another reason to not use prelink - incremental backups.
[...]
thus triggering an unnecessarily large backup.
This is again a bug in your backup tool. I backup by duplicity with:
# https://bugzilla.redhat.com/show_bug.cgi?id=666143 touch /var/lib/prelink/force && time /etc/cron.daily/prelink time rpm -Vva 2>/dev/null|perl -ne 's/^[.]{7}[.T][.] . // or next;chomp;print "- $_\n" if -f;' >$RPMSAFE [...] --exclude-filelist $RPMSAFE \
You are missing the main point - how much extra CPU and disk I/O is that going to take during the backup?
Gordan
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@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
On Thu, 8 Sep 2011 11:38:19 +0200, Jan Kratochvil jan.kratochvil@redhat.com wrote:
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@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.
That argument is bogus since on a sanely configured flash system most of write-heavy /var things should be on tmpfs anyway. There is an (ignored) rhbz ticket filed for it.
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.
Bogus for servers where things tend to load once and stay running for months.
Please keep at the facts and not trying to find any possible reason why to avoid prelink.
I could also invite you to stick to the facts and very realistic common use-cases without trying to justify using prelink at all costs.
Gordan
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@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@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Quoting Gordan Bobic gordan@bobich.net:
I accept that there may be cases where it is useful in some measure - I just don't think it should be on by default.
At this point either, I dont think it should be default either. Nothing against anyone. I just don't think the project needs another hurdle to combat at this point.
If there in fact is a 10% speed boost, maybe discussing prelinking all the dev tools would be appropriate. :)
On Tue, 6 Sep 2011 19:01:57 +0200 Jan Kratochvil jan.kratochvil@redhat.com wrote:
On Tue, 06 Sep 2011 17:39:55 +0200, Gordan Bobic wrote:
Can you elaborate as to why? My experience and measurements show that prelink does more harm than good more offten than not. I can think of a lot of reasons to not use it, and very few reasons to use it.
It speeds up the program startup up to 50% (you can Google out various benchmarks). As almost any performance feature it sure comes with more complexity of the ELF files handling. The most easy ELF files processing would be with -O0 code - so why do we build the programs with -O2?
Citation needed? ;) All the benchmarks I have seen have been in the 10-15% range, and that only for packages that load a large number of libraries at startup time. (openoffice, konqueror, etc).
Nowadays some people do not consider performance as anything to care about so in such case it is understandable they do not see a need for prelink.
It is true that if program is written in C it is usually fast enough. But specifically ARM may be the only popoular platform where I do not find the C programs fast enough, though.
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.
kevin
On Tue, 06 Sep 2011 19:15:45 +0200, Kevin Fenzi wrote:
Citation needed? ;)
http://lwn.net/Articles/341244/ If I can get a 50% speed up to a program's startup times,
All the benchmarks I have seen have been in the 10-15% range,
I agree 10% is more realistic. But 1% of speed is about 1.5 year of the whole GCC team work so even 10% is more than GCC can improve in nearby years.
With LD_DEBUG=all one can see the whole startup part of ld.so being skipped on prelinked executables so apparently prelink saves some work.
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).
Thanks, Jan
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. The Systemtap testsuite (packaged as systemtap-testsuite) for example contains some explicit checks to see whether or not you can properly observe prelinked executables. So 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.
Cheers,
Mark
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. The Systemtap testsuite (packaged as systemtap-testsuite) for example contains some explicit checks to see whether or not you can properly observe prelinked executables. So 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.
Gordan
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.
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
- 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
On 09/06/2011 04:39 PM, Gordan Bobic wrote:
On Tue, 06 Sep 2011 11:34:43 -0400, William Cohen wcohen@redhat.com wrote:
Would it be possible to get the new prelink rpm pulled into arm builds?
The prelink arm support (rhbz#733089) is available in:
Can you elaborate as to why? My experience and measurements show that prelink does more harm than good more offten than not. I can think of a lot of reasons to not use it, and very few reasons to use it.
This seems to be a general argument against prelink, not ARM-specific. If there's any special ARM-related reason not to prelink, then it makes sense to do something different from other Fedora arches. But if there isn't, we should not diverge unnecessarily.
Andrew.
On Thu, Sep 8, 2011 at 10:42 AM, Andrew Haley aph@redhat.com wrote:
On 09/06/2011 04:39 PM, Gordan Bobic wrote:
On Tue, 06 Sep 2011 11:34:43 -0400, William Cohen wcohen@redhat.com wrote:
Would it be possible to get the new prelink rpm pulled into arm builds?
The prelink arm support (rhbz#733089) is available in:
Can you elaborate as to why? My experience and measurements show that prelink does more harm than good more offten than not. I can think of a lot of reasons to not use it, and very few reasons to use it.
This seems to be a general argument against prelink, not ARM-specific. If there's any special ARM-related reason not to prelink, then it makes sense to do something different from other Fedora arches. But if there isn't, we should not diverge unnecessarily.
I agree. Most of the discussion in this thread seems to be based upon opinion not raw facts. Alot of the prelink stuff seems to come down to certain preferences or use case. I think we should follow upstream, its not like it can't be enabled/disable on a case by case basis anyway.
Peter
tor 2011-09-08 klockan 12:31 +0100 skrev Peter Robinson:
I agree. Most of the discussion in this thread seems to be based upon opinion not raw facts. Alot of the prelink stuff seems to come down to certain preferences or use case. I think we should follow upstream, its not like it can't be enabled/disable on a case by case basis anyway.
Agreed, and it's trivial to disable prelink if you do not want it. Simply do not install the prelink package on your system and things will carry on as usual with no prelinking getting done. This can be done either manually during install by selecting to customize the package set, in an install kickstart, or after the install. If done after install then you may want to tell prelink to undo the prelinking first.
So far I have not seen any ARM specific arguments at all regarding why prelink is less suitable on ARM in all cases than on the other arches.
Specific use cases is handled by selecting if you want prelink installed or not, just as is done for the other arches.
Regards Henirk
On Tuesday, September 06, 2011 10:34:43 AM William Cohen wrote:
Would it be possible to get the new prelink rpm pulled into arm builds?
The prelink arm support (rhbz#733089) is available in:
its not something that we can deny, we should ask jakub to push updates for f14 and f15 so we can pull them in, from memory OOo needs prelink to build.
Dennis
-
Andrew Haley -
Dennis Gilmore -
Gordan Bobic -
Henrik Nordström -
itamar -
Jan Kratochvil -
Jon -
Kevin Fenzi -
Mark Wielaard -
Martin Dengler -
omalleys＠msu.edu -
Peter Robinson -
William Cohen