From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759445Ab2EKSoo (ORCPT ); Fri, 11 May 2012 14:44:44 -0400 Received: from mx2.parallels.com ([64.131.90.16]:32776 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759075Ab2EKSom (ORCPT ); Fri, 11 May 2012 14:44:42 -0400 Message-ID: <4FAD5DA2.70803@parallels.com> Date: Fri, 11 May 2012 15:42:42 -0300 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 , , Pekka Enberg Subject: Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree References: <1336758272-24284-1-git-send-email-glommer@parallels.com> <1336758272-24284-5-git-send-email-glommer@parallels.com> <4FAD531D.6030007@parallels.com> <4FAD566C.3000804@parallels.com> <4FAD585A.4070007@parallels.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [187.105.248.83] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/11/2012 03:32 PM, Christoph Lameter wrote: > On Fri, 11 May 2012, Glauber Costa wrote: > >> Thank you in advance for your time reviewing this! > > Where do I find the rationale for all of this? Trouble is that pages can > contain multiple objects f.e. so accounting of pages to groups is a bit fuzzy. > I have not followed memcg too much since it is not relevant (actual > it is potentially significantly harmful given the performance > impact) to the work loads that I am using. > It's been spread during last discussions. The user-visible part is documented in the last patch, but I'll try to use this space here to summarize more of the internals (it can also go somewhere in the tree if needed): We want to limit the amount of kernel memory tasks inside a memory cgroup use. slab is not the only one of them, but it is quite significant. For that, the least invasive, and most reasonable way we found to do it, is to create a copy of each slab inside the memcg. Or almost: we lazy create them, so only slabs that are touched by the memcg are created. So we don't mix pages from multiple memcgs in the same cache - we believe that would be too confusing. /proc/slabinfo reflects this information, by listing the memcg-specific slabs. This also appears in a memcg-specific memory.kmem.slabinfo. Also note that accounting is not done until kernel memory is limited. And if no memcg is limited, the code is wrapped inside static_key branches. So it should be completely patched out if you don't put stuff inside memcg. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx167.postini.com [74.125.245.167]) by kanga.kvack.org (Postfix) with SMTP id 15EA28D0020 for ; Fri, 11 May 2012 14:44:46 -0400 (EDT) Message-ID: <4FAD5DA2.70803@parallels.com> Date: Fri, 11 May 2012 15:42:42 -0300 From: Glauber Costa MIME-Version: 1.0 Subject: Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree References: <1336758272-24284-1-git-send-email-glommer@parallels.com> <1336758272-24284-5-git-send-email-glommer@parallels.com> <4FAD531D.6030007@parallels.com> <4FAD566C.3000804@parallels.com> <4FAD585A.4070007@parallels.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Christoph Lameter Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, kamezawa.hiroyu@jp.fujitsu.com, Tejun Heo , Li Zefan , Greg Thelen , Suleiman Souhlal , Michal Hocko , Johannes Weiner , devel@openvz.org, Pekka Enberg On 05/11/2012 03:32 PM, Christoph Lameter wrote: > On Fri, 11 May 2012, Glauber Costa wrote: > >> Thank you in advance for your time reviewing this! > > Where do I find the rationale for all of this? Trouble is that pages can > contain multiple objects f.e. so accounting of pages to groups is a bit fuzzy. > I have not followed memcg too much since it is not relevant (actual > it is potentially significantly harmful given the performance > impact) to the work loads that I am using. > It's been spread during last discussions. The user-visible part is documented in the last patch, but I'll try to use this space here to summarize more of the internals (it can also go somewhere in the tree if needed): We want to limit the amount of kernel memory tasks inside a memory cgroup use. slab is not the only one of them, but it is quite significant. For that, the least invasive, and most reasonable way we found to do it, is to create a copy of each slab inside the memcg. Or almost: we lazy create them, so only slabs that are touched by the memcg are created. So we don't mix pages from multiple memcgs in the same cache - we believe that would be too confusing. /proc/slabinfo reflects this information, by listing the memcg-specific slabs. This also appears in a memcg-specific memory.kmem.slabinfo. Also note that accounting is not done until kernel memory is limited. And if no memcg is limited, the code is wrapped inside static_key branches. So it should be completely patched out if you don't put stuff inside memcg. -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [PATCH v2 04/29] slub: always get the cache from its page in kfree Date: Fri, 11 May 2012 15:42:42 -0300 Message-ID: <4FAD5DA2.70803@parallels.com> References: <1336758272-24284-1-git-send-email-glommer@parallels.com> <1336758272-24284-5-git-send-email-glommer@parallels.com> <4FAD531D.6030007@parallels.com> <4FAD566C.3000804@parallels.com> <4FAD585A.4070007@parallels.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Christoph Lameter Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org, Tejun Heo , Li Zefan , Greg Thelen , Suleiman Souhlal , Michal Hocko , Johannes Weiner , devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org, Pekka Enberg On 05/11/2012 03:32 PM, Christoph Lameter wrote: > On Fri, 11 May 2012, Glauber Costa wrote: > >> Thank you in advance for your time reviewing this! > > Where do I find the rationale for all of this? Trouble is that pages can > contain multiple objects f.e. so accounting of pages to groups is a bit fuzzy. > I have not followed memcg too much since it is not relevant (actual > it is potentially significantly harmful given the performance > impact) to the work loads that I am using. > It's been spread during last discussions. The user-visible part is documented in the last patch, but I'll try to use this space here to summarize more of the internals (it can also go somewhere in the tree if needed): We want to limit the amount of kernel memory tasks inside a memory cgroup use. slab is not the only one of them, but it is quite significant. For that, the least invasive, and most reasonable way we found to do it, is to create a copy of each slab inside the memcg. Or almost: we lazy create them, so only slabs that are touched by the memcg are created. So we don't mix pages from multiple memcgs in the same cache - we believe that would be too confusing. /proc/slabinfo reflects this information, by listing the memcg-specific slabs. This also appears in a memcg-specific memory.kmem.slabinfo. Also note that accounting is not done until kernel memory is limited. And if no memcg is limited, the code is wrapped inside static_key branches. So it should be completely patched out if you don't put stuff inside memcg.