Dynamic symbol table

[Karl Vogel]

Lubos Lunak <l.lunak at suse.cz> wrote in
news:200407161545.31019.l.lunak at suse.cz: 

> On Friday 16 of July 2004 14:00, Karl Vogel wrote:

>> 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.

I've read your messages on the subject. But maybe you were using a 
desktop system with a fast 7200RPM disk?.. while my laptop has a slow 
4500RPM disk.

Or.. maybe I did something wrong :)


>> 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 :) ? 

Guess so... mine is! 

>  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.

I'm gonna play with this idea in the weekend.. we'll see..

But.. I guess it all depends on the machine you're using.. 

e.g.

* if your machine has only 64Mb RAM, then madvise'ing 25Mb isn't going 
to be very practical. (but as you pointed out.. only fools run KDE with 
64Mb :)

* the 'lot of seeking' argument also depends on the level of disk 
fragmentation (check google for 'fibmap.c' which can show you how 
scattered your file is). Who is to say that your 25Mb can be read with 
less seeking than a 24Mb file :)   -- one thing is for sure.. the bigger 
the file, the more chance you have it is fragmented.

* madvise'ing too much, is also going to have a negative effect on your 
page cache, although this is hard to measure. (and with 1Gb RAM systems 
hardly an issue)


>> 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.

I'm not claiming this ".startup" idea is per-se something for KDE.. it's 
just that I want my KDE to start faster after a coldboot.. so that's 
what I'm trying to achieve.


>  Just bug your favourite kernel/glibc hacker if you find
> one willing to do this.

And get my head bitten off.. no thanks :-)

I'll just do it myself and see what gives..