Re: memcg: slab control

[Balbir Singh <balbir@linux.vnet.ibm.com>]

* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-11-26 10:14:14]:

> On Wed, 25 Nov 2009 15:08:00 -0800 (PST)
> David Rientjes <rientjes@google.com> wrote:
> 
> > Hi,
> > 
> > I wanted to see what the current ideas are concerning kernel memory 
> > accounting as it relates to the memory controller.  Eventually we'll want 
> > the ability to restrict cgroups to a hard slab limit.  That'll require 
> > accounting to map slab allocations back to user tasks so that we can 
> > enforce a policy based on the cgroup's aggregated slab usage similiar to 
> > how the memory controller currently does for user memory.
> > 
> > Is this currently being thought about within the memcg community? 
> 
> Not yet. But I always recommend people to implement another memcg (slabcg) for
> kernel memory. Because
> 
>   - It must have much lower cost than memcg, good perfomance and scalability.
>     system-wide shared counter is nonsense.
>

We've solved those issues mostly! Anyway, I agree that we need another
slabcg, Pavel did some work in that area and posted patches, but they
were mostly based and limited to SLUB (IIRC).
 
>   - slab is not base on LRU. So, another used-memory maintainance scheme should
>     be used.
> 
>   - You can reuse page_cgroup even if slabcg is independent from memcg.
> 
> 
> But, considering user-side, all people will not welcome dividing memcg and slabcg.
> So, tieing it to current memcg is ok for me.
> 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.)
> 

That depends on requirements, hiwatermark is more like a soft limit
than a hard limit and there might be need for hard limits.

> Scalable accounting is the first wall in front of us. Second one will be
> how-to-shrink. About information recording, we can reuse page_cgroup and
> we'll not have much difficulty.
> 
> I hope, at implementing slabcg, we'll not meet very complicated
> racy cases as what we met in memcg. 
>

I think it will be because there is no swapping involved, OOM and rare
race conditions. There is limited slab reclaim possible, but otherwise
I think it is easier to write a slab controller IMHO. 

-- 
	Balbir

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