Re: [PATCH] memcg: do not account memory used for cache creation

[Glauber Costa <glommer@gmail.com>]

On 06/07/2013 06:12 PM, Michal Hocko wrote:
> On Fri 07-06-13 14:11:53, Glauber Costa wrote:
>> On 06/07/2013 01:21 PM, Michal Hocko wrote:
>>> On Tue 04-06-13 18:10:59, Glauber Costa wrote:
>>>> The memory we used to hold the memcg arrays is currently accounted to
>>>> the current memcg.
>>>
>>> Maybe I have missed a train but I thought that only some caches are
>>> tracked and those have to be enabled explicitly by using __GFP_KMEMCG in
>>> gfp flags.
>>
>> No, all caches are tracked. This was set a long time ago, and only a
>> very few initial versions differed from this. This barely changed over
>> the lifetime of the memcg patchset.
>>
>> You probably got confused, due to the fact that only some *allocations*
>
> OK, I was really imprecise. Of course any type of cache might be tracked
> should the allocation (which takes gfp) say so. What I have missed is
> that not only stack allocations say so but also kmalloc itself enforces
> that rather than the actual caller of kmalloc. This is definitely new
> to me. And it is quite confusing that the flag is set only for large
> allocations (kmalloc_order) or am I just missing other parts where
> __GFP_KMEMCG is set unconditionally?
>
> I really have to go and dive into the code.
>

Here is where you are getting your confusion: we don't track caches, we 
track *pages*.

Everytime you pass GFP_KMEMCG to a *page* allocation, it gets tracked.
Every memcg cache - IOW, a memcg copy of a slab cache, sets GFP_KMEMCG 
for all its allocations.

Now, the slub - and this is really an implementation detail - doesn't 
have caches for high order kmalloc caches. Instead, it gets pages 
directly from the page allocator. So we have to mark them explicitly. 
(they are a cache, they are just not implemented as such)

The slab doesn't do that, so all kmalloc caches are just normal caches.

Also note that kmalloc is a *kind* of cache, but not *the caches*. Here 
we are talking dentries, inodes, everything. We track *pages* allocated 
for all those caches.


>> are tracked, but in particular, all cache + stack ones are. All child
>> caches that are created set the __GFP_KMEMCG flag, because those pages
>> should all belong to a cgroup.
>>
>>>
>>> But d79923fa "sl[au]b: allocate objects from memcg cache" seems to be
>>> setting gfp unconditionally for large caches. The changelog doesn't
>>> explain why, though? This is really confusing.
>> For all caches.
>>
>> Again, not all *allocations* are market, but all cache allocations are.
>> All pages that belong to a memcg cache should obviously be accounted.
>
> What is memcg cache?
>

A memcg-local copy of a slab cache.

> Sorry about the offtopic question but why only large allocations are
> marked for tracking? The changelog doesn't mention that.
>

Don't worry about the question. As for the large allocations, I hope the 
answer I provided below addresses it. If you are still not getting it, 
let me know.


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