On 04/07/2013 12:44 PM, Li Zefan wrote:
> Hi,
>
> I'm rebasing this patchset against latest linux-next, and it conflicts with
> "[PATCH v2] memcg: debugging facility to access dangling memcgs." slightly.
>
> That is a debugging patch and will never be pushed into mainline, so should I
> still
On 04/07/2013 12:44 PM, Li Zefan wrote:
Hi,
I'm rebasing this patchset against latest linux-next, and it conflicts with
[PATCH v2] memcg: debugging facility to access dangling memcgs. slightly.
That is a debugging patch and will never be pushed into mainline, so should I
still base this
On Sun 07-04-13 14:00:24, Li Zefan wrote:
> On 2013/4/4 20:00, Michal Hocko wrote:
> > On Wed 03-04-13 17:11:15, Li Zefan wrote:
> >> (I'll be off from my office soon, and I won't be responsive in the
> >> following
> >> 3 days.)
> >>
> >> I'm working on converting memcg to use cgroup->id, and
On Sun 07-04-13 16:44:07, Li Zefan wrote:
> Hi,
>
> I'm rebasing this patchset against latest linux-next, and it conflicts with
> "[PATCH v2] memcg: debugging facility to access dangling memcgs." slightly.
>
> That is a debugging patch and will never be pushed into mainline, so should I
> still
Hi,
I'm rebasing this patchset against latest linux-next, and it conflicts with
"[PATCH v2] memcg: debugging facility to access dangling memcgs." slightly.
That is a debugging patch and will never be pushed into mainline, so should I
still base this patchset on that debugging patch?
Also that
On 2013/4/4 20:00, Michal Hocko wrote:
> On Wed 03-04-13 17:11:15, Li Zefan wrote:
>> (I'll be off from my office soon, and I won't be responsive in the following
>> 3 days.)
>>
>> I'm working on converting memcg to use cgroup->id, and then we can kill
>> css_id.
>>
>> Now memcg has its own
On 2013/4/4 20:00, Michal Hocko wrote:
On Wed 03-04-13 17:11:15, Li Zefan wrote:
(I'll be off from my office soon, and I won't be responsive in the following
3 days.)
I'm working on converting memcg to use cgroup-id, and then we can kill
css_id.
Now memcg has its own refcnt, so when a
Hi,
I'm rebasing this patchset against latest linux-next, and it conflicts with
[PATCH v2] memcg: debugging facility to access dangling memcgs. slightly.
That is a debugging patch and will never be pushed into mainline, so should I
still base this patchset on that debugging patch?
Also that
On Sun 07-04-13 16:44:07, Li Zefan wrote:
Hi,
I'm rebasing this patchset against latest linux-next, and it conflicts with
[PATCH v2] memcg: debugging facility to access dangling memcgs. slightly.
That is a debugging patch and will never be pushed into mainline, so should I
still base this
On Sun 07-04-13 14:00:24, Li Zefan wrote:
On 2013/4/4 20:00, Michal Hocko wrote:
On Wed 03-04-13 17:11:15, Li Zefan wrote:
(I'll be off from my office soon, and I won't be responsive in the
following
3 days.)
I'm working on converting memcg to use cgroup-id, and then we can kill
On Wed 03-04-13 17:11:15, Li Zefan wrote:
> (I'll be off from my office soon, and I won't be responsive in the following
> 3 days.)
>
> I'm working on converting memcg to use cgroup->id, and then we can kill
> css_id.
>
> Now memcg has its own refcnt, so when a cgroup is destroyed, the memcg
On Wed 03-04-13 17:11:15, Li Zefan wrote:
(I'll be off from my office soon, and I won't be responsive in the following
3 days.)
I'm working on converting memcg to use cgroup-id, and then we can kill
css_id.
Now memcg has its own refcnt, so when a cgroup is destroyed, the memcg can
still
On Wed, Apr 03, 2013 at 05:11:15PM +0800, Li Zefan wrote:
> (I'll be off from my office soon, and I won't be responsive in the following
> 3 days.)
>
> I'm working on converting memcg to use cgroup->id, and then we can kill
> css_id.
>
> Now memcg has its own refcnt, so when a cgroup is
On 04/03/2013 01:11 PM, Li Zefan wrote:
> The historical reason that memcg didn't use css_get in some cases, is that
> cgroup couldn't be removed if there're still css refs. The situation has
> changed so that rmdir a cgroup will succeed regardless css refs, but won't
> be freed until css refs
(I'll be off from my office soon, and I won't be responsive in the following
3 days.)
I'm working on converting memcg to use cgroup->id, and then we can kill css_id.
Now memcg has its own refcnt, so when a cgroup is destroyed, the memcg can
still be alive. This patchset converts memcg to always
(I'll be off from my office soon, and I won't be responsive in the following
3 days.)
I'm working on converting memcg to use cgroup-id, and then we can kill css_id.
Now memcg has its own refcnt, so when a cgroup is destroyed, the memcg can
still be alive. This patchset converts memcg to always
On 04/03/2013 01:11 PM, Li Zefan wrote:
The historical reason that memcg didn't use css_get in some cases, is that
cgroup couldn't be removed if there're still css refs. The situation has
changed so that rmdir a cgroup will succeed regardless css refs, but won't
be freed until css refs goes
On Wed, Apr 03, 2013 at 05:11:15PM +0800, Li Zefan wrote:
(I'll be off from my office soon, and I won't be responsive in the following
3 days.)
I'm working on converting memcg to use cgroup-id, and then we can kill
css_id.
Now memcg has its own refcnt, so when a cgroup is destroyed, the
18 matches
Mail list logo
