userland boot time

[Carsten Haitzler (The Rasterman)]

On Mon, 21 Jan 2008 16:18:35 +0000 Andy Green <andy at openmoko.com> babbled:


> > Two interesting approaches to "fix" this would be:
> > 
> > a) Ditch X and write a nice and fast, framebuffer-based SmartPhone
> > application controller. [yes, accelleration may be a problem here]
> 
> Something tells me Carsten will not like to ditch X ;-)
> 
> If I understood his point, he is saying that everywhere he looks he sees
> bloat, and that he can imagine to put some of these apps on a serious
> diet and / or move them out of X init to bite into that 15s he sees
> going that way.  And indeed a settings-*daemon* doesn't need pango, etc.

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.

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.

rememebr too - every x process that starts has to connect to x (that's a round
trip just for that and then at least several more as xlib discovers things
about the display and keeps locally). gdk/gtk then add even more queries on
top. if you have several processes all hammering the cpu to connect to x on
startup it will introduce latency to the startup as everyone contends for
context switches to the same source. minimising what you start up would help.
rolling multiple things into 1 process will help. in the long term we should
dig deep into everything involved in bootup and see what we can do.

one other problem we have is... app startup - runtime. you press a button in
the launcher and have to wait... wait... wait. dialler takes 4 seconds. as does
the phonebook. there are 2 things here to address

1. generic startup times for all processes/apps - what can we do to speed
things up? any ld.so tricks we can play? for gtk apps can we make use of
copy-on-write tricks the maemo guys did with maemo-launcher (it's pure evil.
they literally have a process pre-spawned that has done PARTs of the gtk init -
everything that invovles reading config files, font info off disk etc. but not
the x connection. then they basically message that and fork then dlopen() the
final process and jump to main - i think they actually jump to a special maemo
main call as this will exist if the process knows about quick startup and this
main loop will skip the init he parent already did). with copy on write this
means most of the data read and parsed here will never change - it just is read
later. it's evil - but works.

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

> Sounds good!
> 
> - -Andy
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iD8DBQFHlMXbOjLpvpq7dMoRAgV+AJ98ERA8VofHzbnY7uSjzo0t0Y1drgCfQtJm
> gaHkJ1XpN/q13h69rkSMpG4=
> =6tI1
> -----END PGP SIGNATURE-----


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