From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [PATCH] memcg: do not account memory used for cache creation Date: Fri, 07 Jun 2013 18:45:17 +0400 Message-ID: <51B1F1FD.7000002@gmail.com> References: <1370355059-24968-1-git-send-email-glommer@openvz.org> <20130607092132.GE8117@dhcp22.suse.cz> <51B1B1E9.1020701@parallels.com> <20130607141204.GG8117@dhcp22.suse.cz> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=qXyIu+eDrZkCvpy5C98w3XGes/4lUXwXt453h3seX4I=; b=A8bcMfV5e9yfh/B/NIVSu7ZfdHJtGiBEOYrgMBZgL+FNykfzCjVaOAu3DkQIeiJfYy 6dK9+SqASHhkvsFSNYkMd+UbldP0H/PcNP489c0Hf0mFeSdsADeZKRl4j4VNImoxMCAL GBS5vJ0/ZQNHFvQ6fLvHShqwbE0kYWAAqmgz+TXCYBRWiHy2ISbeG6Rh6JorFNV8Vc30 gnYQEVP9W/zhxPYniaFC7WUF2dKGUbEZvCDN7ZZAgYFsMUf+FfNhGT/gRt4P3rqCyzCj TVzOUFR3G8OD5eTekEde30vIAdG8I3bdAB0VwaiyTHf+MJdw0BfxkkGDd9g7Uhk6f1tg 0R2w== In-Reply-To: <20130607141204.GG8117@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Michal Hocko Cc: Glauber Costa , Glauber Costa , linux-mm@kvack.org, cgroups@vger.kernel.org, Tejun Heo , Johannes Weiner , kamezawa.hiroyu@jp.fujitsu.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: email@kvack.org