Re: memcg: slab control

[David Rientjes <rientjes@google.com>]

On Thu, 26 Nov 2009, KAMEZAWA Hiroyuki wrote:

> But, considering user-side, all people will not welcome dividing memcg and slabcg.
> So, tieing it to current memcg is ok for me.

Agreed.

> like...
> ==
> 	struct mem_cgroup {
> 		....
> 		....
> 		struct slab_cgroup slabcg; (or struct slab_cgroup *slabcg)
> 	}
> ==
> 
> But we have to use another counter and another scheme, another implemenation
> than memcg, which has good scalability and more fuzzy/lazy controls.
> (For example, trigger slab-shrink when usage exceeds hiwatermark, not limit.)
> 

We're only really interested in using memcg and slabcg together for 
accounting all memory allotted to a particular cgroup.  I'm trying to 
imagine a scenario where someone would want to account and enforce hard 
slab limits without using memcg as well.  If there are none (and one of 
the reasons we're trying to illicit discussion is to determine everyone's 
requirements for such a feature), we can probably tie them together 
without worrying about incurring unnecessary overhead by using the memcg 
framework that isn't related to slab accounting.

I think the ideal userspace API would be simply to add slab accounting to 
the memcg's limit_in_bytes if a memcg option were enabled for a cgroup.  I 
don't think it would be helpful to add a ratio of that limit for slab, 
though, since it's very difficult to predict the usage for a particular 
workload.

--
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>