On 03/05/2011 00:21, Herbert Poetzl wrote:
> On Mon, May 02, 2011 at 11:20:30PM +0100, Gordan Bobic wrote:
>
>> On 02/05/2011 23:14, Roderick A. Anderson wrote:
>>> I've got myself confused again. Could someone confirm or deny
>>> how unification affects memory usage.
>
>>> I was under the impression that if a unified (hard linked)
>>> "program" was started by one guest the code for it went into
>>> the text area of memory and any needed data area was allocated
>>> from the heap. Then when another guest started the same
>>> program kernel-magic happened and basically the same code was
>>> used but a new chunk of heap was allocated/used for its data.
>
>>> I'd like to make a simplified drawing of how the Linux-Vserver
>>> way with unification saves memory. Have I got it all wrong?
>
>> I believe the memory unification only applies to the shared
>> memory mmap-ed from hard-linked DLLs. If you have the same
>> glibc unified across all your guests, only one instance of it
>> will be in memory. Unified executables won't save you memory in
>> this way.
>
> why not?
>
>> What you will gain on all unified files, however, is caching
>> efficiency, as you won't end up with multiple copies of the
>> same file being cached separately.
>
> so why should the read only mappings (code)
> not be shared when executing the _same_
> binary twice?
I'm not actually sure. I'd just assumed that since the binary itself
doesn't usually end up as shared memory, except for the shared
libraries, it doesn't end up getting shared in the same way as the
memory used by DLLs. Did I get that wrong? Do binary executables get
mmaped at runtime same as shared libraries?
Gordan
Received on Tue May 3 00:33:39 2011