Messages in this thread | | | Date | Fri, 17 Feb 2006 13:44:11 +0100 | From | Herbert Poetzl <> | Subject | Re: (pspace,pid) vs true pid virtualization |
| |
On Fri, Feb 17, 2006 at 05:16:06AM -0700, Eric W. Biederman wrote: > Herbert Poetzl <herbert@13thfloor.at> writes: > > > On Fri, Feb 17, 2006 at 03:57:26AM -0700, Eric W. Biederman wrote: > >> As for that. When I mad that suggestion to Herbert Poetzl > >> his only concern was that a smart init might be too heavy weight > >> for lightweight vserver. Generally I like the idea. > > > > well, may I remind that this solution would require _two_ > > init processes for each guest, which could easily make up > > 300-400 unnecessary processes in a lightweight server > > setup? > > I take it seriously enough that I remembered the concern, > and I think it is legitimate. Figuring out how to safely > set the policy is a challenge. That is something a > user space daemon trivially gets right. > > The kernel side of a process is about 10K if the user space > side was also lightweight we could have the entire > per process cost in the 30K range. 30K*400 = 12000K = 12M.
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 :)
> 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?
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 :)
best, Herbert
> If we can get a permission checking model in the kernel right > it is potentially much cheaper, to have an enter model. > > Having user space as a backup to that is still interesting. > > >> > (Read the last sentence, and in case you're wondering, no I don't have > >> > any children in real life) > >> > >> Speaking of that. One of my coworkers mentioned that it is unfortunate > >> that our names don't have the double meaning. So it was suggested we > >> call them > >> > >> Speaking of that problematic naming. One of my coworkers mentioned that > >> it is unfortunate that our set of names does not have a double meaning. > >> After that the suggestion came up to call them families, instead of guest > >> or pidspaces. Although I guess calling them guests is about as bad :) > > > > well, at least Guests or VEs are terms already used by > > existing projects, where pspace sounds somewhat strange. > > > > at the same time I'd like to point out that *spaces is > > a good name for the building blocks, but we definitely > > have to name the 'construct' different, i.e. a 'guest' > > (or VPS or VE or whatever) is _more_ than just a p-space > > it's the sum of all *-spaces required to make it look > > like a real linux system. > > I totally agree. Sorry. This was meant as a humerous tangent! > I thought the smiley and the fact I was looking for a name > with a double meaning that would have made it easier to get > confused would have made that clear! > > Oh well such is confusion an email :) > > 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/
| |