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
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, 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, 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, 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, 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:
Paul (??) Menage wrote:
> On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>> >
>> > >mutex_lock(&container_mutex);
>> > >set_bit(CONT_RELEASABLE, &cont->flags);
>> > >- if (atomic_dec_and_test(&c
On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> >mutex_lock(&container_mutex);
> >set_bit(CONT_RELEASABLE, &cont->flags);
> >- if (atomic_dec_and_test(&css->refcnt)) {
> >- check_for_release(cont);
> >- }
>
On 7/16/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
- if (notify_on_release(cont)) {
+ if (atomic_dec_and_test(&css->refcnt) && notify_on_release(cont)) {
This seems like a good idea, as long as atomic_dec_and_test() isn't
noticeably more expensive than atomic_dec(). I assume it sh
On 7/16/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
Hi, Paul,
I've run into a strange problem with css_put(). After the changes for
notify_on_release(), the css_put() routine can now block and it blocks on
the container_mutex. This implies that css_put() cannot be called if
1. We cannot block
10 matches
Mail list logo
