kdeinit problem: LD_BIND_NOW cached by glibc

[karl.vogel at telenet.be]

Lubos Lunak <l.lunak at suse.cz> writes:

>> Time for a test...
>>
>> ----- te.c ---
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <dlfcn.h>
>>
>> int main(int argc, char *argv[])
>> {
>>         void *handle;
>>         int i;
>>
>>         unsetenv("LD_BIND_NOW");
>>         for(i= 0; i<100;i++) {
>
>  Ah ... I was wondering why a simple dlopen can take up to one minute here. 
> You almost got me.

Well it was to show the difference more pronounced, even with only 1 dlopen
it is clear that it takes longer:

$ time ./te /usr/lib/libkdeinit_konsole.so

real    0m0.217s
user    0m0.165s
sys     0m0.007s
$ export LD_BIND_NOW=1
$ time ./te /usr/lib/libkdeinit_konsole.so

real    0m0.343s
user    0m0.316s
sys     0m0.010s


>  You forgot '-L$KDEDIR/lib -lkparts'. Otherwise you cannot have 100 dlopen's 
> done within 227ms (in your first case there's probably only a handful of 
> symbol being resolved and bound).

No I didn't.. it was just to prove a point.. the point being that the
LD_BIND_NOW can't be unsetenv'ed.

Ofcourse actually using symbols from the dlopen'ed lib will increase the
time spend.

>> I also verified this with libltdl and got the same results. This clearly
>> shows that unsetenv("LD_BIND_NOW") has no effect on the dlopen.
>>
>> This is with glibc 2.3.3 (glibc-2.3.3-74) on Fedora Core 3.
>
>  SUSE 9.2 , glibc-2.3.3-118.
>
>> Working around this for kdeinit is possible, but will be hackish.
>
>  The question is if this really matters. Is 60ms on 1,4GHz machine really 

I would say so.. don't forget that all the libs that are pulled in due
to dependent libs are also completely resolved.. if it really didn't
matter, we wouldn't have lazy binding in glibc :-)

The resolving stage also means that more pages are read from disk and
that the memory footprint is bigger, since the touched up relocations
aren't shared in memory.

> worth it? Maybe we should just modify startkde not to set LD_BIND_NOW in case 
> KDE_IS_PRELINKED is set. People caring so much about speed are probably using 
> prelink anyway.

The immediate binding was not only done for faster loading, it also increases
the amount of shared pages between kde apps. I'm not 100% sure if this last
bit is valid for prelinked exe's. Prelink has conflict sections which are used
to touch up relocations, it might be that those are used when dlopening another
lib, causing pages to be COW'ed.