Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754337Ab2E2Qia (ORCPT ); Tue, 29 May 2012 12:38:30 -0400 Received: from mx2.parallels.com ([64.131.90.16]:41508 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753906Ab2E2Qi3 (ORCPT ); Tue, 29 May 2012 12:38:29 -0400 Message-ID: <4FC4FAF6.8060900@parallels.com> Date: Tue, 29 May 2012 20:36:06 +0400 From: Glauber Costa User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Christoph Lameter CC: , , , , Tejun Heo , Li Zefan , Greg Thelen , Suleiman Souhlal , Michal Hocko , Johannes Weiner , , David Rientjes , Pekka Enberg Subject: Re: [PATCH v3 12/28] slab: pass memcg parameter to kmem_cache_create References: <1337951028-3427-1-git-send-email-glommer@parallels.com> <1337951028-3427-13-git-send-email-glommer@parallels.com> <4FC4F04F.1070401@parallels.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [188.255.67.70] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2015 Lines: 51 On 05/29/2012 08:33 PM, Christoph Lameter wrote: > On Tue, 29 May 2012, Glauber Costa wrote: > >>> Ok this only duplicates the kmalloc arrays. Why not the others? >> >> It does duplicate the others. >> >> First it does a while look on the kmalloc caches, then a list_for_each_entry >> in the rest. You probably missed it. > > There is no need to separately duplicate the kmalloc_caches. Those are > included on the cache_chain. > >>>> @@ -2543,7 +2564,12 @@ kmem_cache_create (const char *name, size_t size, >>>> size_t align, >>>> cachep->ctor = ctor; >>>> cachep->name = name; >>>> >>>> + if (g_cpucache_up>= FULL) >>>> + mem_cgroup_register_cache(memcg, cachep); >>> >>> What happens if a cgroup was active during creation of slab xxy but >>> then a process running in a different cgroup uses that slab to allocate >>> memory? Is it charged to the first cgroup? >> >> I don't see this situation ever happening. kmem_cache_create, when called >> directly, will always create a global cache. It doesn't matter which cgroups >> are or aren't active at this time or any other. We create copies per-cgroup, >> but we create it lazily, when someone will touch it. > > How do you detect that someone is touching it? kmem_alloc_cache will create mem_cgroup_get_kmem_cache. (protected by static_branches, so won't happen if you don't have at least non-root memcg using it) * Then it detects which memcg the calling process belongs to, * if it is the root memcg, go back to the allocation as quickly as we can * otherwise, in the creation process, you will notice that each cache has an index. memcg will store pointers to the copies and find them by the index. From this point on, all the code of the caches is reused (except for accounting the page) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/