lkml.org 
[lkml]   [2006]   [Feb]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: RFC [patch 13/34] PID Virtualization Define new task_pid api
On Tue, Jan 31, 2006 at 08:39:19PM -0800, Linus Torvalds wrote:
>
>
> On Tue, 31 Jan 2006, Eric W. Biederman wrote:
> >
> > Yes. Although there are a few container lifetimes problems with
> > that approach. Do you want your container alive for a long time
> > after every process using it has exited just because someone has
> > squirrelled away their pid. While container lifetime issues crop up
> > elsewhere as well PIDs are by far the worst, because it is current
> > safe to store a PID indefinitely with nothing worse that PID wrap
> > around.
>
> Are people really expecting to have a huge turn-over on containers? It
> sounds like this shouldn't be a problem in any normal circumstance:
> especially if you don't even do the "big hash-table per container"
> approach, who really cares if a container lives on after the last
> process exited?
>
> I'd have expected that the major user for this would end up being
> ISP's and the like, and I would not expect the virtual machines to be
> brought up all the time.

well, really depends, as far as I can tell the
number of guest (container) (re)starts can be as
high as one per second (in extreme cases) while
the entire setup doesn't have more than 50-100
containers at the same time, and usually 'runs'
for more than a few months without reboot ...

but agreed, the typical number of container
creations and deletions will be around one per
hour or day ...

> If it's a problem, you can do the same thing that the "struct
> mm_struct" does: it has life-time issues because a mm_struct actually
> has to live for potentially a _long_ time (zombies) but at the same
> time we want to free the data structures allocated to the mm_struct as
> soon as possible, notably the VMA's and the page tables.
>
> So a mm_struct uses a two-level counter, with the "real" users
> (who need the page tables etc) incrementing one ("mm_users"), and
> the "secondary" ones (who just need to have an mm_struct pinned,
> but are ok with an empty VM being attached) incrementing the other
> ("mm_count").

yes, we already do something very similar in
Linux-VServer, basically differentiating between
'active users' and 'passive references' ...

> The same approach might be valid for "containers": you can destroy most of
> the associated container when the actual processes are gone, but keep just
> the empty container around until all secondary references are finally also
> gone.
>
> It's pretty simple: the secondary reference starts at 1 - with the
> "primary" counter being the single ref to the secondary. Then freeing a
> primary does:
>
> if (atomic_dec_and_test(&container->primary_counter)) {
> .. free the core resources here ..
>
> /* then release the ref from the primary to secondary */
> secondary_free(container);
> }
>
> (for "mm_struct", the primary is dropped "mmput()" and the secondary is
> dropped with "mmdrop()", which is absolutely horrid naming. Please name
> things better than I did ;)

best,
Herbert

> Linus
> -
> 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/
-
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-02 06:16    [W:0.083 / U:1.668 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site