Re: memcg: slab control

[David Rientjes <rientjes@google.com>]

On Thu, 26 Nov 2009, Pavel Emelyanov wrote:

> I'm ready to resurrect the patches and port them for slab.
> But before doing it we should answer one question.
> 

Do you have a pointer to your latest implementation that you proposed for 
slab?

> Consider we have two kmalloc-s in a kernel code - one is
> user-space triggerable and the other one is not. From my
> POV we should account for the former one, but should not
> for the latter.
> 
> If so - how should we patch the kernel to achieve that goal?
> 

I think all slab allocations should be accounted for based on current's 
memcg other than those done in hardirq context, annotating slab 
allocations doesn't seem scalable.  Whether the accounting is done on a 
task level or cgroup level isn't really a problem for us since we don't 
move tasks amongst cgroups.  I imagine there've been previous restrictions 
on that put into place with the memcg so this doesn't seem like a 
slabcg-specific requirement anyway.

The problem on the freeing side is mapping the object back to the cgroup 
that allocated it.  We'd also need to map the object to the context in 
which it was allocated to determine whether we should decrement the 
counter or not.  How do you propose doing that without a considerable 
overhead in memory consumption, fastpath branch, and cache cold slabcg 
lookups?

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