On Tue, May 03, 2011 at 12:25:20AM +0100, Gordan Bobic wrote:
> 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.
why 'just assume' things, why not test them out first,
especially if it is rather simple to test, e.g.
cat /proc/meminfo >/tmp/a ; /bin/dash.static -c 'cat /proc/meminfo >/tmp/b; /bin/dash.static -c "cat /proc/meminfo >/tmp/c"'
comparison of a,b, and c gives a noticeable difference
in the 'Mapped' memory between a and b, but no difference
between b and c ...
> Did I get that wrong?
> Do binary executables get mmaped at runtime same as
> shared libraries?
no, but the parts are mapped quite similar, and if the
mapping already exists, the kernel can reuse the read
only pages and even the read/write pages as long as
the copy on write page is not written to ...
in general, the key is to have the same inode and device
information to start with, then all caches and mappings
will be shared where possible, even for 'normal files'
Received on Tue May 3 01:07:38 2011