On Mon 29-10-12 16:26:02, Tejun Heo wrote:
> Hello, Michal.
>
> > Tejun is planning to build on top of that and make some more cleanups
> > in the cgroup core (namely get rid of of the whole retry code in
> > cgroup_rmdir).
>
> I applied 1-3 to the following branch which is based on top of v3.6.
On Mon 29-10-12 16:26:02, Tejun Heo wrote:
Hello, Michal.
Tejun is planning to build on top of that and make some more cleanups
in the cgroup core (namely get rid of of the whole retry code in
cgroup_rmdir).
I applied 1-3 to the following branch which is based on top of v3.6.
Hello, Michal.
> Tejun is planning to build on top of that and make some more cleanups
> in the cgroup core (namely get rid of of the whole retry code in
> cgroup_rmdir).
I applied 1-3 to the following branch which is based on top of v3.6.
Hello, Michal.
Tejun is planning to build on top of that and make some more cleanups
in the cgroup core (namely get rid of of the whole retry code in
cgroup_rmdir).
I applied 1-3 to the following branch which is based on top of v3.6.
Hi,
memcg is the only controller which might fail in its pre_destroy
callback which makes the cgroup core more complicated for no good
reason. This is an attempt to change this unfortunate state.
I have previously posted this as an RFC https://lkml.org/lkml/2012/10/17/246
and the feedback was
Hi,
memcg is the only controller which might fail in its pre_destroy
callback which makes the cgroup core more complicated for no good
reason. This is an attempt to change this unfortunate state.
I have previously posted this as an RFC https://lkml.org/lkml/2012/10/17/246
and the feedback was
(2012/10/17 22:30), Michal Hocko wrote:
> Hi,
> memcg is the only controller which might fail in its pre_destroy
> callback which makes the cgroup core more complicated for no good
> reason. This is an attempt to change this unfortunate state.
>
> I am sending this a RFC because I would like to
On 10/17/2012 05:30 PM, Michal Hocko wrote:
> Hi,
> memcg is the only controller which might fail in its pre_destroy
> callback which makes the cgroup core more complicated for no good
> reason. This is an attempt to change this unfortunate state.
>
> I am sending this a RFC because I would like
Hi,
memcg is the only controller which might fail in its pre_destroy
callback which makes the cgroup core more complicated for no good
reason. This is an attempt to change this unfortunate state.
I am sending this a RFC because I would like to hear back whether the
approach is correct. I thought
Hi,
memcg is the only controller which might fail in its pre_destroy
callback which makes the cgroup core more complicated for no good
reason. This is an attempt to change this unfortunate state.
I am sending this a RFC because I would like to hear back whether the
approach is correct. I thought
On 10/17/2012 05:30 PM, Michal Hocko wrote:
Hi,
memcg is the only controller which might fail in its pre_destroy
callback which makes the cgroup core more complicated for no good
reason. This is an attempt to change this unfortunate state.
I am sending this a RFC because I would like to
(2012/10/17 22:30), Michal Hocko wrote:
Hi,
memcg is the only controller which might fail in its pre_destroy
callback which makes the cgroup core more complicated for no good
reason. This is an attempt to change this unfortunate state.
I am sending this a RFC because I would like to hear
12 matches
Mail list logo
