Thread (57 messages) 57 messages, 4 authors, 2012-12-14

Re: [patch v2 3/6] memcg: rework mem_cgroup_iter to use cgroup iterators

From: Glauber Costa <hidden>
Date: 2012-11-28 09:24:14
Also in: lkml

On 11/28/2012 01:17 PM, Michal Hocko wrote:
On Wed 28-11-12 17:47:59, KAMEZAWA Hiroyuki wrote:
quoted
(2012/11/27 3:47), Michal Hocko wrote:
[...]
quoted
quoted
+		/*
+		 * Even if we found a group we have to make sure it is alive.
+		 * css && !memcg means that the groups should be skipped and
+		 * we should continue the tree walk.
+		 * last_visited css is safe to use because it is protected by
+		 * css_get and the tree walk is rcu safe.
+		 */
+		if (css == &root->css || (css && css_tryget(css)))
+			memcg = mem_cgroup_from_css(css);
Could you note that this iterator will never visit dangling(removed)
memcg, somewhere ?
OK, I can add it to the function comment but the behavior hasn't changed
so I wouldn't like to confuse anybody.
quoted
Hmm, I'm not sure but it may be trouble at shrkinking dangling
kmem_cache(slab).
We do not shrink slab at all. 
yet. However...
Those objects that are in a dead memcg
wait for their owner tho release them which will make the dangling group
eventually go away
quoted
Costa, how do you think ?
In general, I particularly believe it is a good idea to skip dead memcgs
in the iterator. I don't anticipate any problems with shrinking at all.

Basically, we will only ever actively shrink when the memcg is dying, at
which point it is still alive.

After this, it's better to just leave it to vmscan. Whenever there is
pressure, it will go away.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help