Hello,
Sorry again for resurrecting an old thread, but I each time I look
into this issue I realize that I haven't quite understood the details...
On Thu, Oct 13, 2011 at 03:35, Jeff Dike <jd...@addtoit.com> wrote:
> On Thu, Oct 13, 2011 at 01:37:24AM +0200, Riccardo Murri wrote:
>> - however, UML "threads" do share a large portion of the memory, as
>> can be seen from this "ps" output:
>>
>> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
>> 6467 admin 15 0 32.0g 13g 13g S 0.0 27.7 0:00.00
>> kernel64-3.0.4
>> 6466 admin 16 0 32.0g 13g 13g S 0.0 27.7 0:00.15
>> kernel64-3.0.4
>> 6465 admin 22 0 32.0g 13g 13g S 0.0 27.7 0:00.00
>> kernel64-3.0.4
>> 6458 admin 15 0 32.0g 13g 13g S 39.2 27.7 37:00.04
>> kernel64-3.0.4
>> 7437 admin 15 0 12.0g 12g 12g T 52.9 25.6 70:54.39
>> kernel64-3.0.4
>
> UML uses separate address spaces for its processes, thus
> they don't look like threads to anything else, but the bulk of the
> memory (the UML kernel) in those address spaces is shared.
>
I couldn't find many explanations of the SKAS0 mode, and the source
code needs to much kernel-fu for me, so I'm trying to understand it
from Jeff Dike's original announcement:
If I got it right:
- The UML kernel runs in its own process (hence kernel space
separation, enforced by the host kernel), which is the parent of
all the UML processes (one per guest process).
- The UML kernel process ptrace()'s its child processes. (just like
in TT mode, right?)
- Two extra memory pages are allocated per child process, which
are to communicate with the kernel process during syscalls.
Since these pages need to be shared among two host processes (the
UML kernel and its child), they are allocated through mmap()
backed by a temporary file.
Actually, I guess that the whole UML memory is allocated as mmap()'ed
pages from a temporary file: the UML kernel creates a file the size of the
requested memory, and when it has to satisfy a memory allocation it
just mmap()'s a page from that file. Correct?
In addition, *every* syscall generates a SIGTRAP to the UML kernel
process, which handles it. The advantage of SKAS0 over TT is that
memory management syscalls allow the separation of kernel and process
address space, but every other syscall needs to be handled exactly as
in TT: e.g., open() needs to map paths using the UML filesystem, etc.
Right?
Now a final question: according to the above `ps` output, the shared
memory among UML processes is ~13GB each. If the above is correct,
only the UML kernel process should have large shared memory. Is this
due to `top` misreporting shared memory occupation? (CentOS 5.x w/
stock kernel) Or could it be rather a feature of the program that was
running in the UML? (a data-intensive scientific application)
Thank you very much for any explanation.
Best regards,
Riccardo
------------------------------------------------------------------------------
Cloud Services Checklist: Pricing and Packaging Optimization
This white paper is intended to serve as a reference, checklist and point of
discussion for anyone considering optimizing the pricing and packaging model
of a cloud services business. Read Now!
http://www.accelacomm.com/jaw/sfnl/114/51491232/
_______________________________________________
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
