Re: [uml-user] UML, threads and memory usage

[Jeff D. <jd...@ad...>]

On Tue, Dec 06, 2011 at 07:48:40PM +0100, Riccardo Murri wrote:
> 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...

You basically have it all right.

> 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?

A little off the rails here - in TT mode, there is one address space
in which userspace runs, on every context switch, that address space
needs to be completely remapped in order to become the memory of the
switched-in process.

In SKAS, every UML process has a host address space, and UML process
context switching is done by the host, at hardware speed.

> 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)

I can't find any documentation of the exact meaning of SHR, but I'd
guess that it's looking at MAP_SHARED pages, which for a UML process,
is everything.  No utilities are good at accounting for shared
memory.  If you just add up the numbers, you end up far away from
reality.

				Jeff