userland boot time

[Carsten Haitzler (The Rasterman)]

On Tue, 22 Jan 2008 00:26:39 +0000 Richard Purdie <rpurdie at rpsys.net> babbled:

> On Tue, 2008-01-22 at 10:11 +1100, Carsten Haitzler wrote:
> > indeed. in fact it ONLY needs gtk/gdk/glib/pango/ etc. for 1 thing -
> > listening for gconf changes and then modifying x properties. the only thing
> > it needs there is its socket to gconf to get the message - that's a lot of
> > library to 1. load off disk, page in and decompress, 2. resolve symbols
> > etc. to then not use.
> > 3. call gdk_init() whihc does a fair bit mroe than just connect to x.
> > remember we do a lot of init there that doesn't need to be done for this
> > process.
> 
> You also need to keep in mind the games the kernel plays on your behalf
> with dynamic libraries. Each app does not have its own copy of the
> library, these are loaded once and them mmaped read only into each
> process apart from the writable sections which are marked for copy on
> write.

oh - i know. almost every lib i know has a fair number of writable sections -
also the mmap setup does take time as does the search for the lib (statting
multiple dirs for the lib).

> I know OM doesn't use it atm but a lot of the linking overhead can be
> reduced with prelink in two ways. Firstly by analysing the whole system,
> each library can be given a unique load address avoiding any need to
> relocate anything. Secondly, the prelinked tables can be checked for
> validity and used instead of the normal linking process.

yeah. this might help. with C though i have yet to find any real measurable
difference. c++ though seems to have a massive gain.

> > andy is right - i am just digging deep into some example apps i suspect of
> > extra-happy-fun-time bloat that will be slowing down our startup. every MB
> > of disk data we need to load for code, libs or whatever is an MB of data to
> > decompress and given our read speed from flash are in the 2-3MB/sec range
> > on a good day (hell - i was seeing 190KB/sec), thats a LOT of cpu and IO
> > lag/time we spend. trim where it can be trimmed.
> 
> Assuming it does this for each library each time its accessed. Does it?

no - but you may access different parts of the libs - so having to page in
those sections will cost something.

> > 2. some apps (or features) we want to keep around at the touch of a button.
> > dialler, sms read/send, phonebook etc. as they are currently separate
> > processes they should be run in the background but kept hidden until needed
> > - simply dont show a window. maybe in the long run such core things you
> > always want around could/should be considered as dlopen() candidates as
> > modules so they cleanly share the same init code in 1 process, but each
> > simply extends with a new ui/usability component. in general this is bad as
> > instability in one affects the others (as long as the process restarts
> > itself in the event of a crash we should have minimal impact). as i said -
> > only some things you want to have instantly on-tap at all times should do
> > this. others should stick to the process model per app
> 
> Also keep in mind if you start dlopen'ing things prelink can no longer
> help you and dlopen() hits the linker just the same as linking when you
> execute something normally.

yup. i know. but - if you are not talking c++ i am not sure we will get an
appreciable gain?


-- 
Carsten Haitzler (The Rasterman) <raster at openmoko.org>