Thread (12 messages) 12 messages, 2 authors, 2012-05-02

Re: [PATCH 00/23] slab+slub accounting for memcg

From: Glauber Costa <hidden>
Date: 2012-05-02 15:16:38
Also in: linux-mm, lkml

On 04/30/2012 06:43 PM, Suleiman Souhlal wrote:
quoted
I am leaving destruction of caches out of the series, although most
quoted
 of the infrastructure for that is here, since we did it in earlier
 series. This is basically because right now Kame is reworking it for
 user memcg, and I like the new proposed behavior a lot more. We all seemed
 to have agreed that reclaim is an interesting problem by itself, and
 is not included in this already too complicated series. Please note
 that this is still marked as experimental, so we have so room. A proper
 shrinker implementation is a hard requirement to take the kmem controller
 out of the experimental state.
We will have to be careful for cache destruction.
I found several races between allocation and destruction, in my patchset.

I think we should consider doing the uncharging of kmem when
destroying a memcg in mem_cgroup_destroy() instead of in
pre_destroy(), because it's still possible that there are threads in
the cgroup while pre_destroy() is being called (or for threads to be
moved into the cgroup).
I found some problems here as well.
I am trying to work ontop of what Kamezawa posted for pre_destroy() 
rework. I have one or two incorrect uncharging issues to solve, that's 
actually what is holding me for posting a new version.

expected soon

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
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