On Mon 20-01-14 21:16:36, Hugh Dickins wrote:
> On Fri, 17 Jan 2014, Michal Hocko wrote:
> > On Thu 16-01-14 11:15:36, Hugh Dickins wrote:
> >
> > > I don't believe 19f39402864e was responsible for a reference leak,
> > > that came later. But I think it was responsible for the original
> > >
On Mon 20-01-14 21:16:36, Hugh Dickins wrote:
On Fri, 17 Jan 2014, Michal Hocko wrote:
On Thu 16-01-14 11:15:36, Hugh Dickins wrote:
I don't believe 19f39402864e was responsible for a reference leak,
that came later. But I think it was responsible for the original
endless iteration
On Fri, 17 Jan 2014, Michal Hocko wrote:
> On Thu 16-01-14 11:15:36, Hugh Dickins wrote:
>
> > I don't believe 19f39402864e was responsible for a reference leak,
> > that came later. But I think it was responsible for the original
> > endless iteration (shrink_zone going around and around
On Fri, 17 Jan 2014, Michal Hocko wrote:
On Thu 16-01-14 11:15:36, Hugh Dickins wrote:
I don't believe 19f39402864e was responsible for a reference leak,
that came later. But I think it was responsible for the original
endless iteration (shrink_zone going around and around getting root
On Thu 16-01-14 11:15:36, Hugh Dickins wrote:
> On Thu, 16 Jan 2014, Michal Hocko wrote:
> > From 543df5c82f6eec622f669ea322ba6ff03924fded Mon Sep 17 00:00:00 2001
> > From: Michal Hocko
> > Date: Thu, 16 Jan 2014 16:17:13 +0100
> > Subject: [PATCH] memcg: fix css reference leak from
On Thu 16-01-14 11:15:36, Hugh Dickins wrote:
On Thu, 16 Jan 2014, Michal Hocko wrote:
From 543df5c82f6eec622f669ea322ba6ff03924fded Mon Sep 17 00:00:00 2001
From: Michal Hocko mho...@suse.cz
Date: Thu, 16 Jan 2014 16:17:13 +0100
Subject: [PATCH] memcg: fix css reference leak from
On Thu, 16 Jan 2014, Michal Hocko wrote:
> From 543df5c82f6eec622f669ea322ba6ff03924fded Mon Sep 17 00:00:00 2001
> From: Michal Hocko
> Date: Thu, 16 Jan 2014 16:17:13 +0100
> Subject: [PATCH] memcg: fix css reference leak from mem_cgroup_iter
>
> 19f39402864e (memcg: simplify mem_cgroup_iter)
On Thu 16-01-14 09:17:38, Michal Hocko wrote:
> On Wed 15-01-14 13:24:34, Hugh Dickins wrote:
> > On Wed, 15 Jan 2014, Michal Hocko wrote:
[...]
> > > From 560924e86059947ab9418732cb329ad149dd8f6a Mon Sep 17 00:00:00 2001
> > > From: Michal Hocko
> > > Date: Wed, 15 Jan 2014 11:52:09 +0100
> > >
On Wed 15-01-14 13:24:34, Hugh Dickins wrote:
> On Wed, 15 Jan 2014, Michal Hocko wrote:
> > On Wed 15-01-14 10:58:29, Michal Hocko wrote:
> > > On Tue 14-01-14 12:42:28, Hugh Dickins wrote:
> > > > On Tue, 14 Jan 2014, Michal Hocko wrote:
> > [...]
> > > > > Ouch. And thinking about this shows
On Wed 15-01-14 13:24:34, Hugh Dickins wrote:
On Wed, 15 Jan 2014, Michal Hocko wrote:
On Wed 15-01-14 10:58:29, Michal Hocko wrote:
On Tue 14-01-14 12:42:28, Hugh Dickins wrote:
On Tue, 14 Jan 2014, Michal Hocko wrote:
[...]
Ouch. And thinking about this shows that out_css_put is
On Thu 16-01-14 09:17:38, Michal Hocko wrote:
On Wed 15-01-14 13:24:34, Hugh Dickins wrote:
On Wed, 15 Jan 2014, Michal Hocko wrote:
[...]
From 560924e86059947ab9418732cb329ad149dd8f6a Mon Sep 17 00:00:00 2001
From: Michal Hocko mho...@suse.cz
Date: Wed, 15 Jan 2014 11:52:09 +0100
On Thu, 16 Jan 2014, Michal Hocko wrote:
From 543df5c82f6eec622f669ea322ba6ff03924fded Mon Sep 17 00:00:00 2001
From: Michal Hocko mho...@suse.cz
Date: Thu, 16 Jan 2014 16:17:13 +0100
Subject: [PATCH] memcg: fix css reference leak from mem_cgroup_iter
19f39402864e (memcg: simplify
On Wed, 15 Jan 2014, Michal Hocko wrote:
> On Wed 15-01-14 10:58:29, Michal Hocko wrote:
> > On Tue 14-01-14 12:42:28, Hugh Dickins wrote:
> > > On Tue, 14 Jan 2014, Michal Hocko wrote:
> [...]
> > > > Ouch. And thinking about this shows that out_css_put is broken as well
> > > > for subtree walks
On Wed 15-01-14 10:58:29, Michal Hocko wrote:
> On Tue 14-01-14 12:42:28, Hugh Dickins wrote:
> > On Tue, 14 Jan 2014, Michal Hocko wrote:
[...]
> > > Ouch. And thinking about this shows that out_css_put is broken as well
> > > for subtree walks (those that do not start at root_mem_cgroup level).
On Tue 14-01-14 12:42:28, Hugh Dickins wrote:
> On Tue, 14 Jan 2014, Michal Hocko wrote:
> > On Tue 14-01-14 14:27:27, Michal Hocko wrote:
> > > On Mon 13-01-14 17:52:30, Hugh Dickins wrote:
> > > > On one home machine I can easily reproduce (by rmdir of memcgdir during
> > > > reclaim) multiple
On Tue 14-01-14 12:42:28, Hugh Dickins wrote:
On Tue, 14 Jan 2014, Michal Hocko wrote:
On Tue 14-01-14 14:27:27, Michal Hocko wrote:
On Mon 13-01-14 17:52:30, Hugh Dickins wrote:
On one home machine I can easily reproduce (by rmdir of memcgdir during
reclaim) multiple processes stuck
On Wed 15-01-14 10:58:29, Michal Hocko wrote:
On Tue 14-01-14 12:42:28, Hugh Dickins wrote:
On Tue, 14 Jan 2014, Michal Hocko wrote:
[...]
Ouch. And thinking about this shows that out_css_put is broken as well
for subtree walks (those that do not start at root_mem_cgroup level). We
On Wed, 15 Jan 2014, Michal Hocko wrote:
On Wed 15-01-14 10:58:29, Michal Hocko wrote:
On Tue 14-01-14 12:42:28, Hugh Dickins wrote:
On Tue, 14 Jan 2014, Michal Hocko wrote:
[...]
Ouch. And thinking about this shows that out_css_put is broken as well
for subtree walks (those that do
On Tue, 14 Jan 2014, Michal Hocko wrote:
> On Tue 14-01-14 14:27:27, Michal Hocko wrote:
> > On Mon 13-01-14 17:52:30, Hugh Dickins wrote:
> > > On one home machine I can easily reproduce (by rmdir of memcgdir during
> > > reclaim) multiple processes stuck looping forever in mem_cgroup_iter():
> >
On Tue 14-01-14 14:27:27, Michal Hocko wrote:
> On Mon 13-01-14 17:52:30, Hugh Dickins wrote:
> > On one home machine I can easily reproduce (by rmdir of memcgdir during
> > reclaim) multiple processes stuck looping forever in mem_cgroup_iter():
> > __mem_cgroup_iter_next() keeps selecting the
On Tue 14-01-14 14:27:27, Michal Hocko wrote:
> On Mon 13-01-14 17:52:30, Hugh Dickins wrote:
> > On one home machine I can easily reproduce (by rmdir of memcgdir during
> > reclaim) multiple processes stuck looping forever in mem_cgroup_iter():
> > __mem_cgroup_iter_next() keeps selecting the
On Mon 13-01-14 17:52:30, Hugh Dickins wrote:
> On one home machine I can easily reproduce (by rmdir of memcgdir during
> reclaim) multiple processes stuck looping forever in mem_cgroup_iter():
> __mem_cgroup_iter_next() keeps selecting the memcg being destroyed, fails
> to tryget it, returns NULL
On Mon 13-01-14 17:52:30, Hugh Dickins wrote:
On one home machine I can easily reproduce (by rmdir of memcgdir during
reclaim) multiple processes stuck looping forever in mem_cgroup_iter():
__mem_cgroup_iter_next() keeps selecting the memcg being destroyed, fails
to tryget it, returns NULL to
On Tue 14-01-14 14:27:27, Michal Hocko wrote:
On Mon 13-01-14 17:52:30, Hugh Dickins wrote:
On one home machine I can easily reproduce (by rmdir of memcgdir during
reclaim) multiple processes stuck looping forever in mem_cgroup_iter():
__mem_cgroup_iter_next() keeps selecting the memcg
On Tue 14-01-14 14:27:27, Michal Hocko wrote:
On Mon 13-01-14 17:52:30, Hugh Dickins wrote:
On one home machine I can easily reproduce (by rmdir of memcgdir during
reclaim) multiple processes stuck looping forever in mem_cgroup_iter():
__mem_cgroup_iter_next() keeps selecting the memcg
On Tue, 14 Jan 2014, Michal Hocko wrote:
On Tue 14-01-14 14:27:27, Michal Hocko wrote:
On Mon 13-01-14 17:52:30, Hugh Dickins wrote:
On one home machine I can easily reproduce (by rmdir of memcgdir during
reclaim) multiple processes stuck looping forever in mem_cgroup_iter():
On one home machine I can easily reproduce (by rmdir of memcgdir during
reclaim) multiple processes stuck looping forever in mem_cgroup_iter():
__mem_cgroup_iter_next() keeps selecting the memcg being destroyed, fails
to tryget it, returns NULL to mem_cgroup_iter(), which goes around again.
It's
On one home machine I can easily reproduce (by rmdir of memcgdir during
reclaim) multiple processes stuck looping forever in mem_cgroup_iter():
__mem_cgroup_iter_next() keeps selecting the memcg being destroyed, fails
to tryget it, returns NULL to mem_cgroup_iter(), which goes around again.
It's
28 matches
Mail list logo
