Re: memcg: slab control

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

* Suleiman Souhlal <suleiman@google.com> [2009-11-26 04:52:00]:

> On 11/26/09, Pavel Emelyanov <xemul@parallels.com> wrote:
> > > Aren't there patches to make the kernel track which cgroup caused
> >  > which disk I/O? If so, it should be possible to charge the bios to the
> >  > right cgroup.
> >  >
> >  > Maybe one way to decide which kernel allocations should be accounted
> >  > would be to look at the calling context: If the allocation is done in
> >  > user context (syscall), then it could be counted towards that user,
> >  > while if the allocation is done in interrupt or kthread context, it
> >  > shouldn't be accounted.
> >  >
> >  > Of course, this wouldn't be perfect, but it might be a good enough
> >  > approximation.
> >
> >
> > I disagree. Bio-s are allocated in user context for all typical reads
> >  (unless we requested aio) and are allocated either in pdflush context
> >  or (!) in arbitrary task context for writes (e.g. via try_to_free_pages)
> >  and thus such bio/buffer_head accounting will be completely random.
> 
> Yes, that's why I pointed out that you can account to the right cgroup
> if you track who caused the I/O (which, I imagine, should already be
> done by the block i/o bandwidth controller, or similar).
>

We can do so, we do that for task I/O accounting today and it works
quite well for the applications I've applied them to.
 
> For most other allocations, on the other hand, accounting to the
> current context should be fine.
> 

Absolutely! Except when the context is a kernel thread like
pdflush/ksm, etc. 

> >  One of the way to achieve the goal I can propose the following (it's
> >  not perfect, but just smth to start discussion from).
> >
> >  We implement support for accounting based on a bit on a kmem_cache
> >  structure and mark all kmalloc caches as not-accountable. Then we grep
> >  the kernel to find all kmalloc-s and think - if a kmalloc is to be
> >  accounted we turn this into kmem_cache_alloc() with dedicated
> >  kmem_cache and mark it as accountable.
> 
> That sounds like a lot of work. :-)
>

Hmm.. yes, it does, but I wonder if there are better alternatives. 

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