lkml.org 
[lkml]   [2007]   [Feb]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 3/7] containers (V7): Add generic multi-subsystem API to containers
    On 2/12/07, Srivatsa Vaddagiri <vatsa@in.ibm.com> wrote:
    > On Mon, Feb 12, 2007 at 12:15:24AM -0800, menage@google.com wrote:
    > > +/*
    > > + * Call css_get() to hold a reference on the container; following a
    > > + * return of 0, this container subsystem state object is guaranteed
    > > + * not to be destroyed until css_put() is called on it. A non-zero
    > > + * return code indicates that a reference could not be taken.
    > > + *
    > > + */
    > > +
    >
    > Why can't we reuse container->count (or container_group->ref) to
    > refcount the per-subsystem object attached to a container? I think
    > that is how it is done for cpusets? That would make css_get/put
    > unnecessary?

    I did consider that approach at one point. The reason I rejected it
    was that then container->count would no longer even vaguely represent
    the number of processes in a container. Now that we have the
    container_group object, we have to use that for counting the number of
    processes in a container anyway, so that objection goes away.

    However, I think it's important to be able to provide some kind of a
    reference count that subsystems can grab (e.g. to store a reference in
    a non-task object such as a file struct) without taking manage_mutex
    or callback_mutex (since that would be excessively heavyweight) but
    which can still be "frozen" at zero at the point when you're trying to
    destroy a container. Additionally, having it per subsystem will be
    important for when we implement arbitrary binding/unbinding of
    subsystems from hierarchies - at that point we need to be able know
    which subsystems have external reference counts, and hence aren't
    removeable.

    Paul
    -
    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: 2007-02-12 19:43    [W:4.076 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site