lkml.org 
[lkml]   [2006]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: (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/

\
 
 \ /
  Last update: 2006-02-17 13:46    [W:0.116 / U:2.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site