On Tue, 2013-10-22 at 10:35 +0300, Ylinen, Mikko wrote: > Hi Stephane, > > On Mon, Oct 21, 2013 at 5:56 PM, Stéphane Desneux > <[email protected]> wrote: > I saw in the launchpad code that the preloading uses dlopen() > with the flag RTLD_NOW: this forces to load all unresolved > symbols, thus the whole library tree. > > > As the WRT launchpad executes this dlopen() for all binaries > listed in /usr/share/aul/preload*.txt, this leads to loading > nearly 200 libs: > # for x in $( cat /usr/share/aul/preload*.txt); do ldd $x; > done | awk '{print $1}' | sort | uniq | wc -l > 202 > > This is confirmed by reading the list of mapped files for the > process: > # readlink /proc/$(pgrep wrt_launchpad)/map_files/* | grep .so > | sort | uniq | wc -l > 205 > > > Just out of curiosity: will the WRT launchpad daemon startup time > improve if you disable libs dlopen()? > > > This is important for the system startup time.
Perhaps also worth investigating: is RTLD_NOW necessary or can RTLD_LAZY be used? Stéphane said that it causes loading "the while library tree", which is a bit misleading. The same set of libraries should be loaded with and without it. The difference is that symbol resolution happens for everything during loading when RTLD_NOW is used, while it gets deferred for functions until they are actually used with RTLD_LAZY. Symbol resolution can be expensive, so startup time might benefit from not doing it immediately. Functions that never get called don't need to be resolved at all. On the other hand, because functions get called in the forked processes, this work then needs to be done over and over again, which negates the purpose of preloading somewhat. There may be a way to get the best of both worlds: during startup, use RTLD_LAZY. Then sometime later, call dlopen() again for the same modules with RTLD_NOW. According to the dlopen() man page, that has the effect of retroactively resolving all symbols without actually loading the module again. Something else to watch our for is that switching between RTLD_LAZY/RTLD_NOW may also affect which symbols a function call is bound to. This is probably unlikely, but who knows... Another semantic difference is that a module fails to load with RTLD_NOW if any of its symbols cannot be resolved. With RTLD_LAZY, it gets loaded and a runtime error occurs when calling an unresolvable method. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
