uml-patch-2.5.49-1

Can you quickly describe why you didn't use one host process per uml process ?

That would have avoided the need for a /proc/mm extension too I guess.

-Andi

One reason I can think of is that it prevents 'stupid things' happening under a copy of UML from killing the OS UML is running under... Eg. if a process is running under UML because it's not trusted and then turns into a forkbomb, you don't want that taking down the host OS.

Pat
--
Purdue Universtiy ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www-rcd.cc.purdue.edu

You could limit that with an appropiate ulimit.

Also a 'mm-bomb' could be similarly deadly without appropiate host limits.

-Andi

That's just one example... the idea is that you want maximal separation between the guest OS's apps and the host OS. Sort of like "VM" on IBM's series of mainframe architecures. Of course, that's virtualization done in hardware not in software, but the principles are the same; you want a maximal amount of separation between the layers.

Pat
--
Purdue Universtiy ITAP/RCS
Information Technology at Purdue
Research Computing and Storage
http://www-rcd.cc.purdue.edu

That's a nice idea, but in practice you also want efficient execution of processes in the virtual machines and a virtual host implementation that's flexible and easy to maintain.

As usual, you can't have everything so you'll have to make choices here and there. The end result will be a useful compromise between all the different ideas...

Rik

Bravely reimplemented by the knights who say "NIH".
http://www.surriel.com/		http://guru.conectiva.com/
Current spamtrap:  <a href=mailto:"[email protected]">[email protected]</a>

Yes, it would have. And it was done that way during an intermediate stage of the skas work.

There were a few reasons for /proc/mm -
reduce host resource consumption - we still have the mm_struct and
page tables, but we do eliminate the kernel stack, task struct, and associated data
design cleanliness - a UP UML is inherently single-threaded, so it's
pointless to have many host processes when only one of them can be running. A host process maps much more cleanly onto a UML processor than a UML process, and a UML process maps much more cleanly onto a host address space than a host process.
code cleanliness - before /proc/mm, UML manipulated address spaces
through ptrace (PTRACE_M{MAP,UNMAP,PROTECT}). This meant that a process needed to be used as a handle for the address space. Since there's no way of knowing what process in an address space is still going to exist when you want to swap it out, the UML mm_context was a list of task_structs. This made for some nasty-looking code to keep that list up-to-date. It also made for some nasty-looking locking against races between swapout and a thread exiting. Now, the UML mm_context is an int which holds a /proc/mm file descriptor. No lists, no races, it doesn't get any simpler.

Some smaller reasons -
With the address space manipulations in /proc/mm rather than ptrace,
it is possible that a cleaner interface can be found for it. The current /proc/mm write semantics are morally equivalent to the previous ptrace interface, but there is hope that something better can be found. With ptrace, there is no hope.

scheduling fairness - when you have a single-threaded app (in the sense
that there is only one active thread at any given time) that's spreading its work over many threads, the thread that wants to run will compete unfairly in the scheduler with another single-threaded app that is honestly doing all of its work in one thread. The thread in the first app will have accumulated much less time than the second app's thread, and so will have higher priority, even though the two apps may have used the same amount of CPU. With /proc/mm, UML gets much closer to one host process per processor, but doesn't quite make it. There are two host processes, one running the kernel, one running userspace. I'm trying to think of a way of merging them.

It's much nicer to look at ps or top on the host and see a few
(currently four) processes per UML rather than, say, 100.

An unexpected benefit - UML is noticably faster with /proc/mm. That knocked ~10% off its kernel build time. With it doing a build about 40% slower than the host, the 10% reduction in overall run time represents ~25% reduction in UML's virtualization overhead.

Jeff

How does GDB now distinguish between UML processes? Previously, with GDB and UML one would "det; att <host pid>" to trace another process. Will there be equivalent functionality in the new setup?

I was just thinking about hacking the UML PID allocation code so that the UML process PID == host process PID, so that it is easier to debug multiple kernel threads (which are all called "kernel thread" and are hard to align with a specific UML kernel thread).

Will SMP UML "just" be a matter of forking the host process and sharing the /proc/mm file descriptors, along with a UML SMP scheduler and some IPC to decide which host process is running each UML process?

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

It now doesn't. What I'm considering is some function you can call from gdb which would longjmp to the stack that you want to look at and execute a breakpoint (or maybe just hit a breakpoint that was put there earlier).

That should give you equivalent functionality to the current det/att.

Pretty much. It's basically the same as SMP in tt mode, except that starting the idle threads will be slightly different.

Jeff