On Thu 25-10-12 10:42:20, Tejun Heo wrote:
> Hey, Michal.
>
> On Thu, Oct 25, 2012 at 04:37:56PM +0200, Michal Hocko wrote:
> > I am not sure I understand you here. So are you suggesting
> > s/BUG_ON/WARN_ON_ONCE/ in this patch?
>
> Oh, no, I meant that we can do upto patch 3 of this series and
Hey, Michal.
On Thu, Oct 25, 2012 at 04:37:56PM +0200, Michal Hocko wrote:
> I am not sure I understand you here. So are you suggesting
> s/BUG_ON/WARN_ON_ONCE/ in this patch?
Oh, no, I meant that we can do upto patch 3 of this series and then
follow up with proper cgroup core update and then
On Wed 24-10-12 12:25:35, Tejun Heo wrote:
> Hello, Michal.
>
> On Mon, Oct 22, 2012 at 12:30:21PM +0200, Michal Hocko wrote:
> > > > We can still fail inn #3 without this patch becasuse there are is no
> > > > guarantee that a new task is attached to the group. And I wanted to keep
> > > > memcg
On Wed 24-10-12 12:25:35, Tejun Heo wrote:
Hello, Michal.
On Mon, Oct 22, 2012 at 12:30:21PM +0200, Michal Hocko wrote:
We can still fail inn #3 without this patch becasuse there are is no
guarantee that a new task is attached to the group. And I wanted to keep
memcg and generic
Hey, Michal.
On Thu, Oct 25, 2012 at 04:37:56PM +0200, Michal Hocko wrote:
I am not sure I understand you here. So are you suggesting
s/BUG_ON/WARN_ON_ONCE/ in this patch?
Oh, no, I meant that we can do upto patch 3 of this series and then
follow up with proper cgroup core update and then
On Thu 25-10-12 10:42:20, Tejun Heo wrote:
Hey, Michal.
On Thu, Oct 25, 2012 at 04:37:56PM +0200, Michal Hocko wrote:
I am not sure I understand you here. So are you suggesting
s/BUG_ON/WARN_ON_ONCE/ in this patch?
Oh, no, I meant that we can do upto patch 3 of this series and then
Hello, Michal.
On Mon, Oct 22, 2012 at 12:30:21PM +0200, Michal Hocko wrote:
> > > We can still fail inn #3 without this patch becasuse there are is no
> > > guarantee that a new task is attached to the group. And I wanted to keep
> > > memcg and generic cgroup parts separated.
> >
> > Yes, but
Hello, Michal.
On Mon, Oct 22, 2012 at 12:30:21PM +0200, Michal Hocko wrote:
We can still fail inn #3 without this patch becasuse there are is no
guarantee that a new task is attached to the group. And I wanted to keep
memcg and generic cgroup parts separated.
Yes, but all other
On Fri 19-10-12 13:24:05, Tejun Heo wrote:
> Hello, Michal.
>
> On Fri, Oct 19, 2012 at 03:32:45PM +0200, Michal Hocko wrote:
> > On Thu 18-10-12 15:41:48, Tejun Heo wrote:
> > > Hello, Michal.
> > >
> > > On Wed, Oct 17, 2012 at 03:30:46PM +0200, Michal Hocko wrote:
> > > > Now that
On Fri 19-10-12 13:24:05, Tejun Heo wrote:
Hello, Michal.
On Fri, Oct 19, 2012 at 03:32:45PM +0200, Michal Hocko wrote:
On Thu 18-10-12 15:41:48, Tejun Heo wrote:
Hello, Michal.
On Wed, Oct 17, 2012 at 03:30:46PM +0200, Michal Hocko wrote:
Now that mem_cgroup_pre_destroy
Hello, Michal.
On Fri, Oct 19, 2012 at 03:32:45PM +0200, Michal Hocko wrote:
> On Thu 18-10-12 15:41:48, Tejun Heo wrote:
> > Hello, Michal.
> >
> > On Wed, Oct 17, 2012 at 03:30:46PM +0200, Michal Hocko wrote:
> > > Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
> > >
On Fri, Oct 19, 2012 at 05:33:18PM +0800, Li Zefan wrote:
> On 2012/10/17 21:30, Michal Hocko wrote:
> > Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
> > safely move on and forbit all the callbacks to fail. The last missing
> > piece is moving cgroup_call_pre_destroy after
On Thu 18-10-12 15:46:06, Tejun Heo wrote:
> On Thu, Oct 18, 2012 at 03:41:48PM -0700, Tejun Heo wrote:
> > Note that the patch is broken in a couple places but it does show the
> > general direction. I'd prefer if patch #3 simply makes pre_destroy()
> > return 0 and drop
On Thu 18-10-12 15:41:48, Tejun Heo wrote:
> Hello, Michal.
>
> On Wed, Oct 17, 2012 at 03:30:46PM +0200, Michal Hocko wrote:
> > Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
> > safely move on and forbit all the callbacks to fail. The last missing
> > piece is moving
On Fri 19-10-12 17:33:18, Li Zefan wrote:
> On 2012/10/17 21:30, Michal Hocko wrote:
> > Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
> > safely move on and forbit all the callbacks to fail. The last missing
> > piece is moving cgroup_call_pre_destroy after
On 2012/10/17 21:30, Michal Hocko wrote:
> Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
> safely move on and forbit all the callbacks to fail. The last missing
> piece is moving cgroup_call_pre_destroy after cgroup_clear_css_refs so
> that css_tryget fails so no new charges
On 2012/10/17 21:30, Michal Hocko wrote:
Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
safely move on and forbit all the callbacks to fail. The last missing
piece is moving cgroup_call_pre_destroy after cgroup_clear_css_refs so
that css_tryget fails so no new charges for
On Fri 19-10-12 17:33:18, Li Zefan wrote:
On 2012/10/17 21:30, Michal Hocko wrote:
Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
safely move on and forbit all the callbacks to fail. The last missing
piece is moving cgroup_call_pre_destroy after cgroup_clear_css_refs
On Thu 18-10-12 15:41:48, Tejun Heo wrote:
Hello, Michal.
On Wed, Oct 17, 2012 at 03:30:46PM +0200, Michal Hocko wrote:
Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
safely move on and forbit all the callbacks to fail. The last missing
piece is moving
On Thu 18-10-12 15:46:06, Tejun Heo wrote:
On Thu, Oct 18, 2012 at 03:41:48PM -0700, Tejun Heo wrote:
Note that the patch is broken in a couple places but it does show the
general direction. I'd prefer if patch #3 simply makes pre_destroy()
return 0 and drop __DEPRECATED_clear_css_refs
On Fri, Oct 19, 2012 at 05:33:18PM +0800, Li Zefan wrote:
On 2012/10/17 21:30, Michal Hocko wrote:
Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
safely move on and forbit all the callbacks to fail. The last missing
piece is moving cgroup_call_pre_destroy after
Hello, Michal.
On Fri, Oct 19, 2012 at 03:32:45PM +0200, Michal Hocko wrote:
On Thu 18-10-12 15:41:48, Tejun Heo wrote:
Hello, Michal.
On Wed, Oct 17, 2012 at 03:30:46PM +0200, Michal Hocko wrote:
Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
safely move on
On Thu, Oct 18, 2012 at 03:41:48PM -0700, Tejun Heo wrote:
> Note that the patch is broken in a couple places but it does show the
> general direction. I'd prefer if patch #3 simply makes pre_destroy()
> return 0 and drop __DEPRECATED_clear_css_refs from mem_cgroup_subsys.
> Then, I can pull the
Hello, Michal.
On Wed, Oct 17, 2012 at 03:30:46PM +0200, Michal Hocko wrote:
> Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
> safely move on and forbit all the callbacks to fail. The last missing
> piece is moving cgroup_call_pre_destroy after cgroup_clear_css_refs so
>
Hello, Michal.
On Wed, Oct 17, 2012 at 03:30:46PM +0200, Michal Hocko wrote:
Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
safely move on and forbit all the callbacks to fail. The last missing
piece is moving cgroup_call_pre_destroy after cgroup_clear_css_refs so
that
On Thu, Oct 18, 2012 at 03:41:48PM -0700, Tejun Heo wrote:
Note that the patch is broken in a couple places but it does show the
general direction. I'd prefer if patch #3 simply makes pre_destroy()
return 0 and drop __DEPRECATED_clear_css_refs from mem_cgroup_subsys.
Then, I can pull the
Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
safely move on and forbit all the callbacks to fail. The last missing
piece is moving cgroup_call_pre_destroy after cgroup_clear_css_refs so
that css_tryget fails so no new charges for the memcg can happen.
The callbacks are also
Now that mem_cgroup_pre_destroy callback doesn't fail finally we can
safely move on and forbit all the callbacks to fail. The last missing
piece is moving cgroup_call_pre_destroy after cgroup_clear_css_refs so
that css_tryget fails so no new charges for the memcg can happen.
The callbacks are also
28 matches
Mail list logo
