Stuff Michael Meeks is doing
Older items: 2008: ( J F M A M J J A ), 2007: ( J F M A M J J A S O N D ), 2006, 2005, 2004, 2003, 2002, 2001, 2000, 1999, legacy html
There are a number of patches floating around that are intended to accelerate cold time startup of eg. the GNOME desktop, that seem attractive but are rather unhelpful for real world use
The premise of them is that if (as you mmap a shared library) you force the kernel to load it all, then you will get vastly better I/O behavior as it is linked & as the app starts up, since the mapped files (DSOs) are accessed fairly randomly. The premise is correct.
Where this all breaks down of course is that - what is optimal on a 1st / cold start (with lots of memory) is often extremely sub-optimal on a 2nd start
eg. after 2 hours of evolution use, lots of the code which is never touched will be paged out - to make space for other more live data. If we insist on paging that code back in - we have an evil situation - where now we have lots of scattered missing fragments. ie. by forcing 'everything' into memory we necessarily have to seek the missing [seldom used] pieces, seek, read them at great cost.
This phenomenon also bites OO.o where we do a similar trick, and causes pain on loaded / small memory machines on 2nd start. However - since this is in our app we can fix this.
Of course - again, only the kernel can know that this library has already been mmapped & that we don't now want to force page it all in. Only the kernel knows (during cold boot) that we have shed-loads of pristine, unused pages sitting around - and thus we should be aggressively pre-loading mmapped files. Only the kernel (ideally) knows what happened wrt. I/O last time during the execve of this app, what it mapped, and what it used. So - basically we're back to the old axiom for anyone comparing Linux with Win32 I/O performance: Linux I/O scheduling sucks - try to work around it.
Unfortunately this can't be worked around efficiently outside the kernel.
Furthermore, it is acutely unfortunate that the kernel hackers are just amazingly reluctant to provide sharp tools to examine how bad the I/O situation is. It being ~impossible to reliably simulate a cold-start without a hard re-boot. There being no quick way to drop all caches, file backed pages etc.
mincoresyscall that could be used to determine if a shlib was mapped by someone else - I guess it could be useful for glibc. Of course - one might want to guess how sane the kernel will be wrt. seeks if you ask for pages 1,2,3, 5, 7,8 to be read. Either way - writing a separate application that renders the OO.o splash seems the only way to go here.