preloading of binaries

[Lubos Lunak]

 Hello,

 I'd need some people to test the the following hack. In startkde, before KDE 
is loaded, a small utility mmap()'s basic large libraries used by KDE and 
walks over them, causing them to be all loaded into memory, and they'll stay 
cached (I think OO.o uses a similar hack). As the mmap() is done with 
MADV_WILLNEED, this should cause sequential reads of large chunks from the 
disk[1], instead of small random access reads which kernel uses otherwise as 
the parts of the binaries are paged in[2].

 How to test it:
- Edit preload.cpp, adjust prefixes, and adjust sizes of libraries. The sizes 
are the value in the column 'File off' next to the '.bss' segment as reported 
by 'objdump --headers' on the binary. If you strip the libraries, you can 
simply use the size.
- Add calling preload to startkde, before any KDE binary is used (i.e. right 
after the 'startkde: Starting up...' echo.
- Use your wristwatch ;)  [3].

 For me the times are 18,1s without preload with cold cache, 16,4s with 
preload and 11,1s when already cached (logout and startkde again). Not much, 
but probably worth it. Now I'd need some data from more people, especially if 
somebody has somewhat slower HDD or has 2.6 kernel. I tried also with DMA 
turned off, which reduced my 35+MiB/s HDD's performance just to about 2MiB/s, 
and there was no real difference, and in fact when I preloaded too much, it 
even had negative effect on the performance.

 I tried the same also in kdeinit when it dlopens modules, but I couldn't see 
any noticeable difference, as those binaries are <1MiB in size, so that 
probably doesn't make much sense. See kinit.patch if you want to try 
yourself.

[1] In case you build and use Qt from the same directory like I do, I suggest 
applying the attached qt.patch. As already said here by somebody, ld is far 
from creating the library as one large sequential area of disk.
[2] I'd be interested if somebody could test what the difference with 2.6 
kernel is, as I heard rumours somewhere (here?) that 2.6 will do a better job 
at loading binaries.
[3] You need to empty your caches of course for testing this. Compiling and 
running the attached a.cpp should do that (wait for it to be killed by OOM 
killer or break it when your computer starts hitting swap).

-- 
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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qt.patch
Type: text/x-diff
Size: 800 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-optimize/attachments/20040308/1eaa935c/qt.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: preload.cpp
Type: text/x-c++src
Size: 1718 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-optimize/attachments/20040308/1eaa935c/preload.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a.cpp
Type: text/x-c++src
Size: 196 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-optimize/attachments/20040308/1eaa935c/a.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kinit.patch
Type: text/x-diff
Size: 2539 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-optimize/attachments/20040308/1eaa935c/kinit.bin