Re: (pspace,pid) vs true pid virtualization

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

On Fri, Feb 17, 2006 at 05:16:06AM -0700, Eric W. Biederman wrote:
> Herbert Poetzl <[email protected]> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux