(pspace,pid) vs true pid virtualization

From: Serge E. Hallyn
Date: Wed Feb 15 2006 - 09:57:54 EST


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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/