Re: memcg: slab control

[KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>]

On Thu, 26 Nov 2009 14:20:31 +0530
Balbir Singh <balbir@linux.vnet.ibm.com> wrote:

> * 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! 
yes. but our solution is for page faults.
resolution of slab allocation is much more fine grained and often.

> 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.
> 
My point is that most of the kernel codes cannot work well when kmalloc(small area)
returns NULL.



> > 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. 
> 
yes ;)

Thanks,
-Kame

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