On 7/19/07, Paul Menage <[EMAIL PROTECTED]> wrote:
On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> Thinking out loud again, can we add can_destroy() callbacks?
>
What would the exact semantics of such a callback be?
Since for proper interaction with release agents we need the subsystem
On 7/17/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
Thinking out loud again, can we add can_destroy() callbacks?
What would the exact semantics of such a callback be?
Since for proper interaction with release agents we need the subsystem
to notify the framework when a subsystem object become
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 Wed, Jul 18, 2007 at 11:00:39AM +0530, Balbir Singh wrote:
> Thinking out loud again, can we add can_destory() callbacks?
I remember suggesting such a callback long before :
http://marc.info/?l=linux-kernel&m=117576241131788&w=2
--
Regards,
vatsa
-
To unsubscribe from this list: send
Balbir Singh wrote:
> Paul (??) Menage wrote:
>> 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_su
Paul (??) Menage wrote:
> 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?
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
Paul (??) Menage wrote:
> 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
Paul M wrote:
> Right, that's what the release agent patch for process containers does
> - there's a file in the hierarchy root called "release_agent" that
> contains the path to the program to run if a notify_on_release
> container goes idle. When you mount the "cpuset" filesystem, it
> automatica
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
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?
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jacks
> 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).
At least for cpusets (the mother of all containers), notify on release
is part of the user visible API of cpusets. The kernel doe
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
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 container_mutex) could check that the refcount is zero
> and free the container structure.
>
Hi, Paul,
That sound
> 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 container_mutex) could check that the refcount is zero
> and free the container structure.
Not just theory ... I've debugged crashes from l
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 container_mutex) could check
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 container_mutex) could check that the refcount is zero
> and free the container s
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
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(&css->refcnt)) {
>> > >- check_for
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 Mon, Jul 16, 2007 at 07:35:01PM -0700, Paul (宝瑠) Menage wrote:
> 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_de
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
Paul (??) Menage wrote:
> 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() can
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
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
2. We already hold the container_mutex
The problem I
26 matches
Mail list logo
