Re: (pspace,pid) vs true pid virtualization

[Hubertus Franke <frankeh@watson.ibm.com>]

Herbert Poetzl wrote:
> 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.

Eric, Herbert.. why do we need an extra process in each and every
pspace.

Why not have single global pspace-init daemon that acts as the reaper
for all pspace-top processes.
Its only at the boundaries of pspaces and with signals were we
seem to have trouble.

The "pspace-init" reaps the signal of all its sub-pspace's top processes
and then "forwards" the signal to processes actually waiting.
Kind of an interposer.
Same way from the other side.

You allocate a pid on behalf of the process you spawn in your pidspace.
You mark in the pid hash of the lookup that this is merely a proxy
and you forward that to the pspace-init where you have a separate lookup
with <pspace-caller,pspace,pid>.

Same with signals, once the signal is reaped by pspace-init and its looked
up who is the parent pspace and the pid in there, we forward it..

Is something like that workable, idiotic (be kind), too intrusive ?

-- Hubertus


> 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

-
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/