John Reiser wrote:
> Many executables used by the installer depend on libgcc_s.so. Searching for
> this library (by ld-linux.so just after execve) takes more than 1% of install
> time. The search tries:
> 2375 open("/lib/tls/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
> 2373 open("/lib/fast-mult/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
> 2372 open("/lib/v5l/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
> 2372 open("/lib/v5l/fast-mult/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
> 2356 open("/lib/tls/v5l/fast-mult/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
> 2355 open("/lib/tls/fast-mult/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
> 2351 open("/lib/tls/v5l/libgcc_s.so.1", O_RDONLY) = -1 ENOENT
> before finding it in /lib. [Those counts in the first column are for less than
> 1/3 of base install on a NSLU2 armel-eabi in low-memory mode.]
joey@kodama:~>time perl -e 'for (1..16625) { open(IN, "/no/file") }'
0.03user 0.03system 0:00.06elapsed 96%CPU (0avgtext+0avgdata 0maxresident)k
So for a typical install on modern hardware, these 16 thousand extra syscalls
use less than 0.1 second.
I don't have my slug handy to try, but 1% of install time sounds very excessive
even there.
Also, when trying to optimise something, it's generally a good idea
to find an optimiation target that yields significantly better than 1%
improvement.. So, for example, optimising partman to not fork > 1 thousand
child processes when building its menu would probably yield a much more
noticeable benefit. There's a bug in the BTS about that too, IIRC.
> The search can be avoided, by forcing it to succeed on the first try:
> export LD_LIBRARY_PATH=/lib
That stikes me as potentially a very dangerous hack. Also, it doesn't
really result in fewer syscalls here:
joey@kodama:~>strace busybox 2>&1 |grep open
open("/etc/ld.so.cache", O_RDONLY) = 5
open("/lib/i686/cmov/libm.so.6", O_RDONLY) = 5
open("/lib/i686/cmov/libc.so.6", O_RDONLY) = 5
joey@kodama:~>LD_LIBRARY_PATH=/lib strace busybox 2>&1 |grep open
open("/lib/tls/i686/sse2/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/sse2/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/tls/sse2/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/tls/sse2/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/tls/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/tls/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/i686/sse2/cmov/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/i686/sse2/libm.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/lib/i686/cmov/libm.so.6", O_RDONLY) = 5
open("/lib/i686/cmov/libc.so.6", O_RDONLY) = 5
IIRC the linker/glibc already has a bug open about its innefficient
attempts to open libraries that arn't there. I don't think we should try
to work around such a bug in the installer.
--
see shy jo
Attachment:
signature.asc
Description: Digital signature