Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Jan 2001 10:55:42 GMT
From:      Cliff Sarginson <cliff@raggedclown.net>
To:        Mike Meyer <mwm@mired.org>, Cliff Sarginson <cliff@raggedclown.net>, Mike Meyer <mwm@mired.org>, Gustavo Vieira Goncalves Coelho Rios <gustavo@ifour.com.br>, questions@FreeBSD.ORG
Subject:   Re: small program eats lot of memory
Message-ID:  <E14KedS-000NHH-00@post.mail.nl.demon.net>

next in thread | raw e-mail | index | archive | help
> Cliff Sarginson <cliff@raggedclown.net> types:
> > > Cliff Sarginson <cliff@raggedclown.net> types:
> > > > On Sunday 21 January 2001 16:48, Mike Meyer wrote:
> > > > > Gustavo Vieira Goncalves Coelho Rios <gustavo@ifour.com.br> types:
> > > > > > I compiled and executed a small program and it's eating about 336
> > > > > > of real memory (rss) and 840 of virtual size memory (vsz), may some
> > > > > > one explain why a simple program eats about 1 MB of memory?
> > > > > You linked it shared, right? That 1MB includes all of every shared
> > > > > library it uses, whether it uses those functions or not.
> > > > Pardon ! It certainly does not ! That is the point of shared libraries -
> > > > the code is *shared* between processes using it. The required code is
> > > > then made dynamically available.
> > > 
> > > Shared libraries are mapped into the memory space of the process. As
> > > such, they are part of the memory of the process, and should be
> > > counted when adding up the memory of the process, so it'll be the rss
> > > (if it's resident) and vsz of the process.
> > > 
> > > Whether or not the physical memory is shared is another question, and
> > > I'll let you all continue to debate that. I will say that, given the
> > > price of disks, if the memory isn't shared, a system with static
> > > binaries might be a better choice than one with dynamic binaries.
> > 
> > So what does the word shared in shared memory mean then :)
> > Hard to see what the point is if all processes load their own copy
> > of shared memory libraries at run time..
> > I think you will find that physically speaking there is only one libc...
> > in memory under the shared model.
> 
> Since you replied to me, and I didn't have an opinion about shared
> libraries being shared on memory or just disk, I'm assuming you're
> claiming that my analysis of the way libc is used and the memory
> counted.
> 
> Checking usage is easy: just truss a binary that uses shared libc, and
> look for it in the output. Here's what I find:
> 
> access("/usr/lib/libc.so.3",0)                   = 0 (0x0)
> open("/usr/lib/libc.so.3",0,027757775424)        = 3 (0x3)
> fstat(3,0xbfbffae4)                              = 0 (0x0)
> read(0x3,0xbfbfeab4,0x1000)                      = 4096 (0x1000)
> mmap(0x0,643072,0x5,0x2,3,0x0)                   = 672337920 (0x28131000)
> mmap(0x281b5000,20480,0x3,0x12,3,0x83000)        = 672878592 (0x281b5000)
> mmap(0x281ba000,81920,0x3,0x1012,-1,0x0)         = 672899072 (0x281ba000)
> close(3)                                         = 0 (0x0)
> 
> I.e. - it gets opened and mmap'ed into memory exactly like I
> said. After it's mapped in, a second area is allocated r/w instead of
> r/x, and a second r/w area is allocated from swap. They are all part
> of the memory used by the process, and show up in the appropriate
> sizes.
Yes, it is mapped into the processes's address space.
It is not copied into it.

Cliff



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E14KedS-000NHH-00>