On 2012/11/1 3:44, Tejun Heo wrote:
> CSS_REMOVED is one of the several contortions which were necessary to
> support css reference draining on cgroup removal. All css->refcnts
> which need draining should be deactivated and verified to equal zero
> atomically w.r.t. css_tryget(). If any one
On 2012/11/1 3:44, Tejun Heo wrote:
CSS_REMOVED is one of the several contortions which were necessary to
support css reference draining on cgroup removal. All css-refcnts
which need draining should be deactivated and verified to equal zero
atomically w.r.t. css_tryget(). If any one isn't
(2012/11/01 4:44), Tejun Heo wrote:
> CSS_REMOVED is one of the several contortions which were necessary to
> support css reference draining on cgroup removal. All css->refcnts
> which need draining should be deactivated and verified to equal zero
> atomically w.r.t. css_tryget(). If any one
(2012/10/31 13:22), Tejun Heo wrote:
> CSS_REMOVED is one of the several contortions which were necessary to
> support css reference draining on cgroup removal. All css->refcnts
> which need draining should be deactivated and verified to equal zero
> atomically w.r.t. css_tryget(). If any one
(2012/10/31 13:22), Tejun Heo wrote:
CSS_REMOVED is one of the several contortions which were necessary to
support css reference draining on cgroup removal. All css-refcnts
which need draining should be deactivated and verified to equal zero
atomically w.r.t. css_tryget(). If any one isn't
(2012/11/01 4:44), Tejun Heo wrote:
CSS_REMOVED is one of the several contortions which were necessary to
support css reference draining on cgroup removal. All css-refcnts
which need draining should be deactivated and verified to equal zero
atomically w.r.t. css_tryget(). If any one isn't
CSS_REMOVED is one of the several contortions which were necessary to
support css reference draining on cgroup removal. All css->refcnts
which need draining should be deactivated and verified to equal zero
atomically w.r.t. css_tryget(). If any one isn't zero, all refcnts
needed to be
Hey, Michal.
On Wed, Oct 31, 2012 at 08:16:02PM +0100, Michal Hocko wrote:
> Sure, it cannot detect races but this wasn't the intention of the check.
> The more important part is that memcg can outlive css and we want to
> catch bugs when we try to charge to an already dead memcg.
cgroup will
On Wed 31-10-12 09:57:39, Tejun Heo wrote:
> Hey, Michal.
>
> On Wed, Oct 31, 2012 at 04:39:26PM +0100, Michal Hocko wrote:
> > > prepare_to_wait(_rmdir_waitq, , TASK_INTERRUPTIBLE);
> > >
> > > - local_irq_disable();
> > > -
> >
> > OK, so the new charges shouldn't come from the IRQ context
CSS_REMOVED is one of the several contortions which were necessary to
support css reference draining on cgroup removal. All css->refcnts
which need draining should be deactivated and verified to equal zero
atomically w.r.t. css_tryget(). If any one isn't zero, all refcnts
needed to be
Hello, Glauber.
On Wed, Oct 31, 2012 at 09:38:32PM +0400, Glauber Costa wrote:
> Because I am allocating an array big enough to hold one entry per memcg.
> The natural array index for this, is the css_id. Obviously, I don't want
> this array to have 65k entries in size, so I resize it (doubling
On 10/31/2012 09:25 PM, Tejun Heo wrote:
> More proper names for these callbacks would be,
>
> ->allocate()
> ->online()
> ->offline()
> ->free()
I support the name change, btw.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On 10/31/2012 09:25 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Oct 31, 2012 at 09:19:51PM +0400, Glauber Costa wrote:
>> I don't see post_create failing as a huge problem. The natural
>> synchronization point would be "right after post_create" - then you can
>> definitely tell that it is online.
Hello,
On Wed, Oct 31, 2012 at 09:19:51PM +0400, Glauber Costa wrote:
> I don't see post_create failing as a huge problem. The natural
> synchronization point would be "right after post_create" - then you can
> definitely tell that it is online. Although this can be viewed a bit as
> "exposing
On 10/31/2012 09:10 PM, Tejun Heo wrote:
> Hello, Glauber.
>
> On Wed, Oct 31, 2012 at 10:06 AM, Glauber Costa wrote:
>> This is not the topic of this thread, but since you brought it:
>> If you take a look at the description patch in the patch I sent, the
>> problem I outlined is that at create
Hello, Glauber.
On Wed, Oct 31, 2012 at 10:06 AM, Glauber Costa wrote:
> This is not the topic of this thread, but since you brought it:
> If you take a look at the description patch in the patch I sent, the
> problem I outlined is that at create time, we don't know anything about
> which will
On 10/31/2012 08:57 PM, Tejun Heo wrote:
> I have a patch queued to add ->pre_destroy() - different from
> Glauber's in that it can't fail, so we'll have
>
> ->create()
> ->post_create()
> ->pre_destroy()
> ->destroy()
>
> Where ->create() may fail but
Hey, Michal.
On Wed, Oct 31, 2012 at 04:39:26PM +0100, Michal Hocko wrote:
> > prepare_to_wait(_rmdir_waitq, , TASK_INTERRUPTIBLE);
> >
> > - local_irq_disable();
> > -
>
> OK, so the new charges shouldn't come from the IRQ context so we cannot
> race with css_tryget but why did we need
On Tue 30-10-12 21:22:39, Tejun Heo wrote:
> CSS_REMOVED is one of the several contortions which were necessary to
> support css reference draining on cgroup removal. All css->refcnts
> which need draining should be deactivated and verified to equal zero
> atomically w.r.t. css_tryget(). If any
On Tue 30-10-12 21:22:39, Tejun Heo wrote:
CSS_REMOVED is one of the several contortions which were necessary to
support css reference draining on cgroup removal. All css-refcnts
which need draining should be deactivated and verified to equal zero
atomically w.r.t. css_tryget(). If any one
Hey, Michal.
On Wed, Oct 31, 2012 at 04:39:26PM +0100, Michal Hocko wrote:
prepare_to_wait(cgroup_rmdir_waitq, wait, TASK_INTERRUPTIBLE);
- local_irq_disable();
-
OK, so the new charges shouldn't come from the IRQ context so we cannot
race with css_tryget but why did we need
On 10/31/2012 08:57 PM, Tejun Heo wrote:
I have a patch queued to add -pre_destroy() - different from
Glauber's in that it can't fail, so we'll have
-create()
-post_create()
-pre_destroy()
-destroy()
Where -create() may fail but none other can.
Hello, Glauber.
On Wed, Oct 31, 2012 at 10:06 AM, Glauber Costa glom...@parallels.com wrote:
This is not the topic of this thread, but since you brought it:
If you take a look at the description patch in the patch I sent, the
problem I outlined is that at create time, we don't know anything
On 10/31/2012 09:10 PM, Tejun Heo wrote:
Hello, Glauber.
On Wed, Oct 31, 2012 at 10:06 AM, Glauber Costa glom...@parallels.com wrote:
This is not the topic of this thread, but since you brought it:
If you take a look at the description patch in the patch I sent, the
problem I outlined is
Hello,
On Wed, Oct 31, 2012 at 09:19:51PM +0400, Glauber Costa wrote:
I don't see post_create failing as a huge problem. The natural
synchronization point would be right after post_create - then you can
definitely tell that it is online. Although this can be viewed a bit as
exposing
On 10/31/2012 09:25 PM, Tejun Heo wrote:
Hello,
On Wed, Oct 31, 2012 at 09:19:51PM +0400, Glauber Costa wrote:
I don't see post_create failing as a huge problem. The natural
synchronization point would be right after post_create - then you can
definitely tell that it is online. Although
On 10/31/2012 09:25 PM, Tejun Heo wrote:
More proper names for these callbacks would be,
-allocate()
-online()
-offline()
-free()
I support the name change, btw.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Hello, Glauber.
On Wed, Oct 31, 2012 at 09:38:32PM +0400, Glauber Costa wrote:
Because I am allocating an array big enough to hold one entry per memcg.
The natural array index for this, is the css_id. Obviously, I don't want
this array to have 65k entries in size, so I resize it (doubling
CSS_REMOVED is one of the several contortions which were necessary to
support css reference draining on cgroup removal. All css-refcnts
which need draining should be deactivated and verified to equal zero
atomically w.r.t. css_tryget(). If any one isn't zero, all refcnts
needed to be
On Wed 31-10-12 09:57:39, Tejun Heo wrote:
Hey, Michal.
On Wed, Oct 31, 2012 at 04:39:26PM +0100, Michal Hocko wrote:
prepare_to_wait(cgroup_rmdir_waitq, wait, TASK_INTERRUPTIBLE);
- local_irq_disable();
-
OK, so the new charges shouldn't come from the IRQ context so we
Hey, Michal.
On Wed, Oct 31, 2012 at 08:16:02PM +0100, Michal Hocko wrote:
Sure, it cannot detect races but this wasn't the intention of the check.
The more important part is that memcg can outlive css and we want to
catch bugs when we try to charge to an already dead memcg.
cgroup will
CSS_REMOVED is one of the several contortions which were necessary to
support css reference draining on cgroup removal. All css-refcnts
which need draining should be deactivated and verified to equal zero
atomically w.r.t. css_tryget(). If any one isn't zero, all refcnts
needed to be
CSS_REMOVED is one of the several contortions which were necessary to
support css reference draining on cgroup removal. All css->refcnts
which need draining should be deactivated and verified to equal zero
atomically w.r.t. css_tryget(). If any one isn't zero, all refcnts
needed to be
CSS_REMOVED is one of the several contortions which were necessary to
support css reference draining on cgroup removal. All css-refcnts
which need draining should be deactivated and verified to equal zero
atomically w.r.t. css_tryget(). If any one isn't zero, all refcnts
needed to be
34 matches
Mail list logo
