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 08:39:51AM -0500, Hubertus Franke wrote:
> 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.

that would probably work, but I think it adds some
complications and might require certain design changes

just to give some ideas:

- how to reach the guest space if there is no 'handle'?
- how to handle hierarchical contexts?

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

yup, could work ...

best,
Herbert

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

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