[Devel] Re: [PATCH 04/10] memcg: Introduce __GFP_NOACCOUNT.

Glauber Costa glommer at parallels.com
Tue Mar 6 10:31:55 PST 2012


On 03/06/2012 08:13 PM, Suleiman Souhlal wrote:
> On Tue, Mar 6, 2012 at 2:36 AM, Glauber Costa<glommer at parallels.com>  wrote:
>> On 03/04/2012 04:10 AM, Suleiman Souhlal wrote:
>>>
>>> Just a few lines below:
>>>
>>>          data = kmalloc_node_track_caller(size, gfp_mask, node);
>>>
>>> -- Suleiman
>>
>> Can't we just make sure those come from the root cgroup's slabs?
>> Then we need no flag.
>
> Do you mean make it so that all kmallocs come from the root cgroup's slabs?
No.

> We would really like to account kmallocs in general (and all the other
> slab types) to the right cgroup...
For the record, even in the scenario where we mark the slabs we want to 
track, I'd still like to account and limit kmallocs. They are a big 
source of memory usage.

What I mean, is that if we can specify which cgroup certain kmallocs 
should be billed against, we could use that to get rid of this GFP flag.
And if we really want another non-kmalloc slab to escape accounting,
then we can use a SLAB flag instead of a GFP flag.

>
> That said, I'm probably going to concentrate on accounting specially
> marked caches only, for now, since there seems to be a strong
> opposition on accounting everything, even though I don't understand
> this point of view.

Give me a couple of days to sketch something on the lines of what I 
described above.

I think that would be a good compromise for us here. If it is also okay 
for Kame, we might have good chances of reaching consensus with that.





More information about the Devel mailing list