userland boot time
rpurdie at rpsys.net
Tue Jan 22 11:22:02 CET 2008
On Tue, 2008-01-22 at 13:19 +1100, Carsten Haitzler wrote:
> On Tue, 22 Jan 2008 00:26:39 +0000 Richard Purdie <rpurdie at rpsys.net> babbled:
> > 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).
If the build system is working properly, it should find it first time.
If its not, the rpath magic is wrong.
> > 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.
In a handheld arm C based system like Poky, I see a measurable
difference in device boot time and application startup time....
> > > 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?
My experiences suggest otherwise. Poky has a prelink .bb recipe and I've
just synced it into OE so it has the eabi fixes too if anyone wants to
More information about the distro-devel