Re: memcg: slab control

[Suleiman Souhlal <suleiman@google.com>]

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

For most other allocations, on the other hand, accounting to the
current context should be fine.

>  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. :-)

-- Suleiman

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