Stuff Michael Meeks is doing |
Older items: 2023: ( J F M A M J ), 2022: ( J F M A M J J A S O N D ), 2021, 2019, 2018, 2017, 2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2009, 2008, 2007, 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.
mincore syscall 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.
My content in this blog and associated images / data under
images/ and data/ directories are (usually)
created by me and (unless obviously labelled otherwise) are licensed under
the public domain, and/or if that doesn't float your boat a CC0
license. I encourage linking back (of course) to help people decide for
themselves, in context, in the battle for ideas, and I love fixes /
improvements / corrections by private mail.
In case it's not painfully obvious: the reflections reflected here are my own; mine, all mine ! and don't reflect the views of Collabora, SUSE, Novell, The Document Foundation, Spaghetti Hurlers (International), or anyone else. It's also important to realise that I'm not in on the Swedish Conspiracy. Occasionally people ask for formal photos for conferences or fun.
Michael Meeks (michael.meeks@collabora.com)