Messages in this thread | | | Date | Wed, 15 Feb 2006 08:59:42 -0600 | From | "Serge E. Hallyn" <> | Subject | (pspace,pid) vs true pid virtualization |
| |
Hi,
the lkml discussion on pid virtualization has been covering many of the issues both relating directly to pid virtualization, and relating to optimizations in the two specific implementations.
However, if we're going to get anywhere, the first decision which we need to make is whether to go with a (container,pid), (pspace,pid) or equivalent pair like approach, or a virtualized pid approach. Linus had previously said that he prefers the former. Since there has been much discussion since then, I thought I'd try to recap the pros and cons of each approach, with the hope that the head Penguins will chime in one more time, after which we can hopefully focus our efforts.
Issues with the (pspace,pid) pair like approach: 1. how do we reap zombies when the "real" init process is not visible from within a container? 2. global process view userspace tools may need to be taught about containers in order to provide any container with a "global pid view". i.e. all tasks could be listed as (pspace,pid), or as pid1/pid2/pid3 where pid1 is creator of pid2's pspace which is creator of pid3's pspace... 3. no half-isolation mode? containers are always fully isolated. This doesn't need to be the case if userspace tools are taught to deal with containerids. On the other hand, it can also be considered one of it's strenghts.
Issues with pid virtualization; 1. maintenance/correctness pids and vpids are now different and must not be mixed. Enforcing this simply in the kernel is a concern. Sparse may be useful here, or simply using different opaque types. 2. slowdown after migration before checkpt, pid==vpid. After restore or migration, vpid = hash(pid) or vice versa.
Please add any issues I've not listed, or correct anything you feel I've misrepresented.
thanks, -serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |