On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
Paul (??) Menage wrote:
> On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>> >
>> > >mutex_lock(&container_mutex);
>> > >set_bit(CONT_RELEASABLE, &con
On 7/17/07, Dave Hansen <[EMAIL PROTECTED]> wrote:
On Tue, 2007-07-17 at 08:49 -0700, Paul (宝瑠) Menage wrote:
> Because as soon as you do the atomic_dec_and_test() on css->refcnt and
> the refcnt hits zero, then theoretically someone other thread (that
> already holds cont
On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
That sounds correct. I wonder now if the solution should be some form
of delegation for deletion of unreferenced containers (HINT: work queue
or kernel threads).
What a great idea. In fact, that's exactly what the release agent
patch already
On 7/17/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
At least for cpusets (the mother of all containers), notify on release
is part of the user visible API of cpusets. The kernel does not remove
cpusets; it runs a user program, /sbin/cpuset_release_agent. That
program might choose to rmdir the
On 7/17/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
Paul M wrote:
> In fact, that's exactly what the release agent
> patch already does.
I'm feeling lazy ;) What's the Subject of that
patch, for my easy searching?
"Support for automatic userspace release agents"
Paul
-
To unsubscribe from th
On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
without too much knowledge of each other. BTW, what are the semantics
of css_put() is it expected to free the container/run the release agent
when the reference count of the container_subsys_state drops to zero?
If you css_put() the last refe
On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
Ok.. so my problem still remains, how do I get a non-blocking atomic
reference increment/decrement routine, that would prevent my
container from being deleted?
css_put() in my new patchset will be non-blocking.
I don't find cpusets using c
401 - 407 of 407 matches
Mail list logo
