Re: shared objects, ELFs and memory usage

Re: shared objects, ELFs and memory usage

[Richard B. Johnson]

On Tue, 6 May 2003, Nir Livni wrote:

> Hi all,
> If this is not the mailing list to ask this question - please let me know
> where should I ask it.
>
> I have an executable whose size is almost 2MB, and it uses a shared object
> that is almost 2MB.
> when I run the process, I see (using "top") that the amount of "used memory"
> raises with 4MB. (make sence...). the process seem to share 2MB ("shared"
> column).
>
> When the process forks, it seems that the amount of "used memory" raises
> with 4MB again.
>
> Does it mean the shared object is not really shared ? That doesn't make
> sence...
>
> Help is appreciated.
> Please CC me because I am not subscribed.
>
> Thanks,
> Nir

If your shared object is truly a shared object, then it is shared.
Use `strace` to trace the startup of your program. You should
see it mmap() some portion of your shared object. You can also
put a pause() in you program, then look at /proc/<PID>/maps and
see what your program has memapped.

Note that merely linking some object files together does not
create a shared object! You need to compile any 'C' code
with the '-shared' parameter, and any assembly code needs
to not use COMM variables. Then you need to link them as

	ld -warn-common -O2 -shared -Map Shared.Map $(OBJS) -o $(SLIB)

...where OBJS is you list of object files, and SLIB is your new
shared library.

You can inspect Shared.Map to see what is in the library. When
you link against the shared library, you need to tell the linker
where to find the runtime file, i.e., you need to use -rpath.


Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips).
Why is the government concerned about the lunatic fringe? Think about it.

shared objects, ELFs and memory usage

[Nir Livni]

Hi all,
If this is not the mailing list to ask this question - please let me know
where should I ask it.

I have an executable whose size is almost 2MB, and it uses a shared object
that is almost 2MB.
when I run the process, I see (using "top") that the amount of "used memory"
raises with 4MB. (make sence...). the process seem to share 2MB ("shared"
column).

When the process forks, it seems that the amount of "used memory" raises
with 4MB again.

Does it mean the shared object is not really shared ? That doesn't make
sence...

Help is appreciated.
Please CC me because I am not subscribed.

Thanks,
Nir

RE: shared objects, ELFs and memory usage

[Nir Livni]

Hi

> 
> > Hi all,
> > If this is not the mailing list to ask this question - 
> please let me 
> > know where should I ask it.
> >
> > I have an executable whose size is almost 2MB, and it uses a shared 
> > object that is almost 2MB. when I run the process, I see 
> (using "top") 
> > that the amount of "used memory" raises with 4MB. (make 
> sence...). the 
> > process seem to share 2MB ("shared" column).
> >
> > When the process forks, it seems that the amount of "used memory" 
> > raises with 4MB again.
> >
> > Does it mean the shared object is not really shared ? That doesn't 
> > make sence...
> >
> > Help is appreciated.
> > Please CC me because I am not subscribed.
> >
> > Thanks,
> > Nir
> 
> If your shared object is truly a shared object, then it is 
> shared. Use `strace` to trace the startup of your program. 
> You should see it mmap() some portion of your shared object. 
> You can also put a pause() in you program, then look at 
> /proc/<PID>/maps and see what your program has memapped.
> 
> Note that merely linking some object files together does not 
> create a shared object! You need to compile any 'C' code with 
> the '-shared' parameter, and any assembly code needs to not 
> use COMM variables. Then you need to link them as
> 
> 	ld -warn-common -O2 -shared -Map Shared.Map $(OBJS) -o $(SLIB)
> 

After compiling and linking my .so with the -shared option,
I've inspected strace output.
I can clearly see that the shared object (which is 2MB size) is NOT being
shared:

1395  open("/usr/local/sharedclient.so", O_RDONLY) = 6
1395  read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\200"...,
1024) = 1024
1395  fstat64(6, {st_mode=S_IFREG|0644, st_size=2079700, ...}) = 0
1395  old_mmap(NULL, 2118824, PROT_READ|PROT_EXEC, MAP_PRIVATE, 6, 0) =
0x401ea000

Any idea why ?
(Please CC me because I am not subscribed)

Thanks,
Nir

> ...where OBJS is you list of object files, and SLIB is your 
> new shared library.
> 
> You can inspect Shared.Map to see what is in the library. 
> When you link against the shared library, you need to tell 
> the linker where to find the runtime file, i.e., you need to 
> use -rpath.
> 
> 
> Cheers,
> Dick Johnson
> Penguin : Linux version 2.4.20 on an i686 machine (797.90 
> BogoMips). Why is the government concerned about the lunatic 
> fringe? Think about it.
> 

Re: shared objects, ELFs and memory usage

[William Lee Irwin III]

On Thu, May 08, 2003 at 12:54:23PM +0300, Nir Livni wrote:
> After compiling and linking my .so with the -shared option,
> I've inspected strace output.
> I can clearly see that the shared object (which is 2MB size) is NOT being
> shared:
> 1395  open("/usr/local/sharedclient.so", O_RDONLY) = 6
> 1395  read(6, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\200"...,
> 1024) = 1024
> 1395  fstat64(6, {st_mode=S_IFREG|0644, st_size=2079700, ...}) = 0
> 1395  old_mmap(NULL, 2118824, PROT_READ|PROT_EXEC, MAP_PRIVATE, 6, 0) =
> 0x401ea000
> Any idea why ?
> (Please CC me because I am not subscribed)

It's called copy-on-write sharing. It is shared with the proviso that
all modified pages are privatized and not committed to disk.


-- wli

RE: shared objects, ELFs and memory usage

[Nir Livni]

OK.
Thanks,
I am beginning to see the full picture now.
But I guess I am still missing something.
In the following "top" output,

Mem:   512396K av,  509208K used,    3188K free,       0K shrd,   10248K
buff
Swap:  522072K av,       0K used,  522072K free                  417244K
cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME 
 1538 unt033     9   0  4528 4524  4128 S     8.9  0.8   0:04 
 1596 unt006    16   0  4540 4536  4132 S     3.1  0.8   0:04 
 1509 unt004    11   0  4528 4524  4128 S     2.9  0.8   0:03 

I understand that about 4MB from each process is shared using copy_on_write.

What does the "cached" portion of the output means ?
I see that almost all the "used" memory is also "cached".
(please CC me)

Thanks,
Nir

> 
> 
> On Thu, May 08, 2003 at 12:54:23PM +0300, Nir Livni wrote:
> > After compiling and linking my .so with the -shared option, I've 
> > inspected strace output. I can clearly see that the shared object 
> > (which is 2MB size) is NOT being
> > shared:
> > 1395  open("/usr/local/sharedclient.so", O_RDONLY) = 6
> > 1395  read(6, 
> > "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\200"...,
> > 1024) = 1024
> > 1395  fstat64(6, {st_mode=S_IFREG|0644, st_size=2079700, ...}) = 0
> > 1395  old_mmap(NULL, 2118824, PROT_READ|PROT_EXEC, 
> MAP_PRIVATE, 6, 0) =
> > 0x401ea000
> > Any idea why ?
> > (Please CC me because I am not subscribed)
> 
> It's called copy-on-write sharing. It is shared with the 
> proviso that all modified pages are privatized and not 
> committed to disk.
> 
> 
> -- wli
>