Dynamic symbol table

[Lubos Lunak]

On Friday 16 of July 2004 14:00, Karl Vogel wrote:
> Lubos Lunak <l.lunak at suse.cz> wrote in
>
> news:200407161252.49575.l.lunak at suse.cz:
> > On Friday 16 of July 2004 12:40, Waldo Bastian wrote:
> >> Would be nice if someone could look into that. Just having a somewhat
> >> convenient to use tool to identify the hot code would already be a
> >> step forward.
> >
> >  Note that ld.so in SUSE9.1 loads whole binary at once into memory
> >  instead of
> > paging it in as needed, which reduces seeking (can be disabled by
> > $LD_NOMADVISE). This was discussed here few months back. I'm not sure
> > if this feature has made it into official glibc yet.
>
> Really?! This seems like a bad idea to me! I did a preload test with
> madvise() on all linked libs and well it took a lot longer than demand
> paging the libs..

 And I did a test as well and it took somewhat shorter than demand paging the 
libs. Makes sense given that seeking is much slower than the actual reading. 
You can search this list archives for madvise for details.

> afterall.. you're reading alot of data that isn't needed 
> directly.

 I somehow doubt this. Since our binaries are not laid in any special way the 
code should be so scattered that I'd expect the majority of the pages to 
loaded in anyway. Loading 10% less pages is not going to be any win if that 
means 50% more seeking.

>
> For systems with gobs of memory and fast disks, I can understand the
> advantage.. but there are still systems with slow disks (laptops) and low
> memory.

 Running KDE :) ? But anyway, we don't have _that_ large binaries. And I'd 
expect the difference to be something like say 25MiB+less seeking vs 
24MiB+lot of seeking. Can you prove in practice that it makes things worse? I 
can prove cases where it makes things better.

>
> If I'm not mistaken.. Windows XP records the pages that are used during the
> first 3 seconds of an executable, and preloads those on the next execute.
> (it's also tied into the defragmenter, so that those pages are kept
> together on disk).
>
> Creating a ".startup" ELF section and only preloading/madvise()'ing that
> would be something similar and it would be do'able without too much code
> effort (see my mail concerning the gcc flags).

 It's definitely not simpler than just one madvise(). And I don't think 
your .startup idea would work. I agree that things can be always done a bit 
better. Just bug your favourite kernel/glibc hacker if you find one willing 
to do this.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/