Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754455Ab2E2RCR (ORCPT ); Tue, 29 May 2012 13:02:17 -0400 Received: from mx2.parallels.com ([64.131.90.16]:47623 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754196Ab2E2RCQ (ORCPT ); Tue, 29 May 2012 13:02:16 -0400 Message-ID: <4FC5008A.1060808@parallels.com> Date: Tue, 29 May 2012 20:59:54 +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> <4FC4FAF6.8060900@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: 1628 Lines: 34 On 05/29/2012 08:52 PM, Christoph Lameter wrote: > Well kmem_cache_alloc cache is the performance critical hotpath. > > If you are already there and doing all of that then would it not be better > to simply count the objects allocated and freed per cgroup? Directly > increment and decrement counters in a cgroup? You do not really need to > duplicate the kmem_cache structure and do not need to modify allocators if > you are willing to take that kind of a performance hit. Put a wrapper > around kmem_cache_alloc/free and count things. Well, I see it as the difference between being a big slower, and a lot slower. Accounting in memcg is hard, specially because it is potentially hierarchical, (meaning you need to nest downwards until your parents). I never discussed that this is, unfortunately, a hotpath. However, I did try to minimize the impact as much as I could. Not to mention that the current scheme is bound to improvement as cgroups improve. One of the things being discussed is to having all cgroups always in the same hierarchy. If that ever happens, we can have the information about the current cgroup stored in a very accessible way, so to make this even faster. This felt like the best way I could do with the current infrastructure, (and again, I did make it free for people not limiting kmem), and is way, way cheaper than doing accounting here. -- 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/