Re: Fixed memory address
On 10/05/2007 03:28 AM, Bert Freudenberg wrote: Would that be possible with the virtualization containers? I don't think vservers messes around with the virtual address space of processes. Btw, if I'm not mistaken, the Linux loader does something similar, so if the relocating step could be skipped, it may help every executable in the system. Exactly. This is what prelink does on F7. I think we could run prelink on the OLPC images from within pilgrim, just before converting it to jffs2. It will result in a slight speedup in startup time, but nothing compared to importing modules that dominates startup time of the Python activities. Or is that already possible because of virtual memory, and the base addresses are just randomized for security reasons? We wouldn't need that kind of security with rainbow, do we? The base address of processes are randomized for security on several Linux distributions, including Fedora. You can disable it globally by doing this: echo 0 /proc/sys/kernel/randomize_va_space But this, of course, it not an option on the OLPC. You can also disable it by setting a flag in your ELF binary. There's a tool to do that, but I can't remember its name right now. It was documented somewhere in the RedHat release notes when they introduced va space randomization. -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fixed memory address
Hi, I think we could run prelink on the OLPC images from within pilgrim, just before converting it to jffs2. It will result in a slight speedup in startup time, but nothing compared to importing modules that dominates startup time of the Python activities. Actually, I did exactly this: # prelink -avm / # reboot And it made no discernible difference (with a stopwatch) to boot time, activity startup time, or activity memory use. It was pretty confusing. If someone wants to see if they can have better luck with it, that'd be fine with me. - Chris. -- Chris Ball [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Fixed memory address
Chris Ball wrote: I think we could run prelink on the OLPC images from within pilgrim, just before converting it to jffs2. It will result in a slight speedup in startup time, but nothing compared to importing modules that dominates startup time of the Python activities. Actually, I did exactly this: # prelink -avm / # reboot And it made no discernible difference (with a stopwatch) to boot time, activity startup time, or activity memory use. It was pretty confusing. If someone wants to see if they can have better luck with it, that'd be fine with me. If it made no change at all to the split second, then I guess the binaries were already prelinked or prelinking is failing for some reason. I said *slight* speedup because I knew it wouldn't matter that much for the kind of libraries we use. The speedup is proportional to the number of relocations done by ld.so, and C binaries don't do that many. There used to be some O(2) behavior in ld.so, but I think Jakub optimzed it to be O(N*log(N)) some time ago, and later on Fedora switched to use the gnu.hash ELF extension to mitigate the problem even further. So my guess is that prelinking might still be beneficial, but the effect is mostly visible for degenerate cases such as Qt/KDE libraries, which have hundreds of classes, each with a huge vtable containing pointers to member functions which have to be relocated even if not used. There should also be some (minor?) memory savings in using prelink, because each page containing a relocation has to be copied per-process. This is the kind of memory problems that we'd never see without the PSS and USS kernel patches, because the VMM and RSS of the application doesn't change when COW occurs! -- \___/ |___| Bernardo Innocenti - http://www.codewiz.org/ \___\ One Laptop Per Child - http://www.laptop.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
