From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [PATCH v3 19/28] slab: per-memcg accounting of slab caches Date: Tue, 29 May 2012 20:13:28 +0400 Message-ID: <4FC4F5A8.9060506@parallels.com> References: <1337951028-3427-1-git-send-email-glommer@parallels.com> <1337951028-3427-20-git-send-email-glommer@parallels.com> <4FC4F42D.6060601@parallels.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4FC4F42D.6060601-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> 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, David Rientjes , Pekka Enberg On 05/29/2012 08:07 PM, Glauber Costa wrote: > On 05/29/2012 06:52 PM, Christoph Lameter wrote: >> On Fri, 25 May 2012, Glauber Costa wrote: >> >>> > This patch charges allocation of a slab object to a particular >>> > memcg. >> Ok so a requirement is to support tracking of individual slab >> objects to cgroups? That is going to be quite expensive since it will >> touch the hotpaths. >> > > No, we track pages. But all the objects in the page belong to the same > cgroup. > Also, please note the following: The code that relays us to the right cache, is wrapped inside a static branch. Whoever is not using more than the root cgroup, will not suffer a single bit. If you are, but your process is in the right cgroup, you will unfortunately pay function call penalty(*), but the code will make and effort to detect that as early as possible and resume. (*) Not even then if you fall in the following categories, that are resolved inline: + if (!current->mm) + return cachep; + if (in_interrupt()) + return cachep; + if (gfp & __GFP_NOFAIL) + return cachep; From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx182.postini.com [74.125.245.182]) by kanga.kvack.org (Postfix) with SMTP id AD8876B007B for ; Tue, 29 May 2012 12:15:51 -0400 (EDT) Message-ID: <4FC4F5A8.9060506@parallels.com> Date: Tue, 29 May 2012 20:13:28 +0400 From: Glauber Costa MIME-Version: 1.0 Subject: Re: [PATCH v3 19/28] slab: per-memcg accounting of slab caches References: <1337951028-3427-1-git-send-email-glommer@parallels.com> <1337951028-3427-20-git-send-email-glommer@parallels.com> <4FC4F42D.6060601@parallels.com> In-Reply-To: <4FC4F42D.6060601@parallels.com> 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, David Rientjes , Pekka Enberg On 05/29/2012 08:07 PM, Glauber Costa wrote: > On 05/29/2012 06:52 PM, Christoph Lameter wrote: >> On Fri, 25 May 2012, Glauber Costa wrote: >> >>> > This patch charges allocation of a slab object to a particular >>> > memcg. >> Ok so a requirement is to support tracking of individual slab >> objects to cgroups? That is going to be quite expensive since it will >> touch the hotpaths. >> > > No, we track pages. But all the objects in the page belong to the same > cgroup. > Also, please note the following: The code that relays us to the right cache, is wrapped inside a static branch. Whoever is not using more than the root cgroup, will not suffer a single bit. If you are, but your process is in the right cgroup, you will unfortunately pay function call penalty(*), but the code will make and effort to detect that as early as possible and resume. (*) Not even then if you fall in the following categories, that are resolved inline: + if (!current->mm) + return cachep; + if (in_interrupt()) + return cachep; + if (gfp & __GFP_NOFAIL) + return cachep; -- 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 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754290Ab2E2QPv (ORCPT ); Tue, 29 May 2012 12:15:51 -0400 Received: from mx2.parallels.com ([64.131.90.16]:51743 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753894Ab2E2QPu (ORCPT ); Tue, 29 May 2012 12:15:50 -0400 Message-ID: <4FC4F5A8.9060506@parallels.com> Date: Tue, 29 May 2012 20:13:28 +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 19/28] slab: per-memcg accounting of slab caches References: <1337951028-3427-1-git-send-email-glommer@parallels.com> <1337951028-3427-20-git-send-email-glommer@parallels.com> <4FC4F42D.6060601@parallels.com> In-Reply-To: <4FC4F42D.6060601@parallels.com> 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 On 05/29/2012 08:07 PM, Glauber Costa wrote: > On 05/29/2012 06:52 PM, Christoph Lameter wrote: >> On Fri, 25 May 2012, Glauber Costa wrote: >> >>> > This patch charges allocation of a slab object to a particular >>> > memcg. >> Ok so a requirement is to support tracking of individual slab >> objects to cgroups? That is going to be quite expensive since it will >> touch the hotpaths. >> > > No, we track pages. But all the objects in the page belong to the same > cgroup. > Also, please note the following: The code that relays us to the right cache, is wrapped inside a static branch. Whoever is not using more than the root cgroup, will not suffer a single bit. If you are, but your process is in the right cgroup, you will unfortunately pay function call penalty(*), but the code will make and effort to detect that as early as possible and resume. (*) Not even then if you fall in the following categories, that are resolved inline: + if (!current->mm) + return cachep; + if (in_interrupt()) + return cachep; + if (gfp & __GFP_NOFAIL) + return cachep;