Messages in this thread | | | Subject | Re: (pspace,pid) vs true pid virtualization | From | (Eric W. Biederman) | Date | Fri, 17 Feb 2006 06:15:20 -0700 |
| |
Herbert Poetzl <herbert@13thfloor.at> writes:
> that's something I'm not so worried about, but a statically > compiled userspace process with 20K sounds unusual in the > time of 2M *libcs :)
For unshared data, a stack and page tables is should be achievable even with glibc but I haven't sat down and done the math. But last I looked if you took out the debug symbols glibc was only 1M.
If glibc can't do it one of the lightweight embedded c libraries certainly should be able to.
>> That is significant but we are still cheap enough that it >> isn't necessarily a show stopper. >> >> I think the cost was only one extra process, for the case where you >> have fakeinit now it would be init, for other cases it would be a >> daemon that gets setup when you initialize the vserver. > > well, depends, currently we do not need a parent to handle > the guest, so there is _no_ waiting process in the light- > weight case either, which makes that two processes for each > guest, no?
As I put it together you don't need a parent. The parent can wait for it or exit the child doesn't care. Usual unix semantics here :)
If you are using a pipe to communicate to the outside world that has to be put someplace, but you can always create a fifo in the filesystem. You could have a single parent for all of the lightweight guests.
Lots of choices on how to put the pieces together.
> anyway, I'm not strictly against having an init process > inside a guest, as long as it is not an essential part > of the overall design, because that would make it much > harder to rip it out later :)
Except for being a child reaper no. Having a process that is the child reaper is interesting mainly because it allows you to get an accurate struct rusage picture of all of the children in pspace.
Eric
- 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/
| |