From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [PATCH v2 04/11] kmem accounting basic infrastructure Date: Mon, 13 Aug 2012 12:36:51 +0400 Message-ID: <5028BCA3.6040506@parallels.com> References: <1344517279-30646-1-git-send-email-glommer@parallels.com> <1344517279-30646-5-git-send-email-glommer@parallels.com> <50253EA8.9080205@jp.fujitsu.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <50253EA8.9080205-+CUm20s59erQFUHtdCDX3A@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Kamezawa Hiroyuki Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, devel-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org, Michal Hocko , Johannes Weiner , Andrew Morton , Christoph Lameter , David Rientjes , Pekka Enberg On 08/10/2012 09:02 PM, Kamezawa Hiroyuki wrote: > (2012/08/09 22:01), Glauber Costa wrote: >> This patch adds the basic infrastructure for the accounting of the slab >> caches. To control that, the following files are created: >> >> * memory.kmem.usage_in_bytes >> * memory.kmem.limit_in_bytes >> * memory.kmem.failcnt >> * memory.kmem.max_usage_in_bytes >> >> They have the same meaning of their user memory counterparts. They >> reflect the state of the "kmem" res_counter. >> >> The code is not enabled until a limit is set. This can be tested by the >> flag "kmem_accounted". This means that after the patch is applied, no >> behavioral changes exists for whoever is still using memcg to control >> their memory usage. >> >> We always account to both user and kernel resource_counters. This >> effectively means that an independent kernel limit is in place when the >> limit is set to a lower value than the user memory. A equal or higher >> value means that the user limit will always hit first, meaning that kmem >> is effectively unlimited. >> >> People who want to track kernel memory but not limit it, can set this >> limit to a very high number (like RESOURCE_MAX - 1page - that no one >> will ever hit, or equal to the user memory) >> >> Signed-off-by: Glauber Costa >> CC: Michal Hocko >> CC: Johannes Weiner >> Reviewed-by: Kamezawa Hiroyuki > > Could you add a patch for documentation of this new interface and a text > explaining the behavior of "kmem_accounting" ? > > Hm, my concern is the difference of behavior between user page accounting and > kmem accounting...but this is how tcp-accounting is working. > > Once you add Documentation, it's okay to add my Ack. > I plan to add documentation in a separate patch. Due to that, can I add your ack to this patch here? Also, I find that the description text in patch0 grew to be quite informative and complete. I plan to add that to the documentation if that is ok with you From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx139.postini.com [74.125.245.139]) by kanga.kvack.org (Postfix) with SMTP id 4DFEF6B0068 for ; Mon, 13 Aug 2012 04:39:59 -0400 (EDT) Message-ID: <5028BCA3.6040506@parallels.com> Date: Mon, 13 Aug 2012 12:36:51 +0400 From: Glauber Costa MIME-Version: 1.0 Subject: Re: [PATCH v2 04/11] kmem accounting basic infrastructure References: <1344517279-30646-1-git-send-email-glommer@parallels.com> <1344517279-30646-5-git-send-email-glommer@parallels.com> <50253EA8.9080205@jp.fujitsu.com> In-Reply-To: <50253EA8.9080205@jp.fujitsu.com> Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Kamezawa Hiroyuki Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org, devel@openvz.org, Michal Hocko , Johannes Weiner , Andrew Morton , Christoph Lameter , David Rientjes , Pekka Enberg On 08/10/2012 09:02 PM, Kamezawa Hiroyuki wrote: > (2012/08/09 22:01), Glauber Costa wrote: >> This patch adds the basic infrastructure for the accounting of the slab >> caches. To control that, the following files are created: >> >> * memory.kmem.usage_in_bytes >> * memory.kmem.limit_in_bytes >> * memory.kmem.failcnt >> * memory.kmem.max_usage_in_bytes >> >> They have the same meaning of their user memory counterparts. They >> reflect the state of the "kmem" res_counter. >> >> The code is not enabled until a limit is set. This can be tested by the >> flag "kmem_accounted". This means that after the patch is applied, no >> behavioral changes exists for whoever is still using memcg to control >> their memory usage. >> >> We always account to both user and kernel resource_counters. This >> effectively means that an independent kernel limit is in place when the >> limit is set to a lower value than the user memory. A equal or higher >> value means that the user limit will always hit first, meaning that kmem >> is effectively unlimited. >> >> People who want to track kernel memory but not limit it, can set this >> limit to a very high number (like RESOURCE_MAX - 1page - that no one >> will ever hit, or equal to the user memory) >> >> Signed-off-by: Glauber Costa >> CC: Michal Hocko >> CC: Johannes Weiner >> Reviewed-by: Kamezawa Hiroyuki > > Could you add a patch for documentation of this new interface and a text > explaining the behavior of "kmem_accounting" ? > > Hm, my concern is the difference of behavior between user page accounting and > kmem accounting...but this is how tcp-accounting is working. > > Once you add Documentation, it's okay to add my Ack. > I plan to add documentation in a separate patch. Due to that, can I add your ack to this patch here? Also, I find that the description text in patch0 grew to be quite informative and complete. I plan to add that to the documentation if that is ok with you -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753616Ab2HMIj7 (ORCPT ); Mon, 13 Aug 2012 04:39:59 -0400 Received: from mx2.parallels.com ([64.131.90.16]:53030 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752967Ab2HMIj6 (ORCPT ); Mon, 13 Aug 2012 04:39:58 -0400 Message-ID: <5028BCA3.6040506@parallels.com> Date: Mon, 13 Aug 2012 12:36:51 +0400 From: Glauber Costa User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20120717 Thunderbird/14.0 MIME-Version: 1.0 To: Kamezawa Hiroyuki CC: , , , , Michal Hocko , Johannes Weiner , Andrew Morton , Christoph Lameter , David Rientjes , Pekka Enberg Subject: Re: [PATCH v2 04/11] kmem accounting basic infrastructure References: <1344517279-30646-1-git-send-email-glommer@parallels.com> <1344517279-30646-5-git-send-email-glommer@parallels.com> <50253EA8.9080205@jp.fujitsu.com> In-Reply-To: <50253EA8.9080205@jp.fujitsu.com> Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/10/2012 09:02 PM, Kamezawa Hiroyuki wrote: > (2012/08/09 22:01), Glauber Costa wrote: >> This patch adds the basic infrastructure for the accounting of the slab >> caches. To control that, the following files are created: >> >> * memory.kmem.usage_in_bytes >> * memory.kmem.limit_in_bytes >> * memory.kmem.failcnt >> * memory.kmem.max_usage_in_bytes >> >> They have the same meaning of their user memory counterparts. They >> reflect the state of the "kmem" res_counter. >> >> The code is not enabled until a limit is set. This can be tested by the >> flag "kmem_accounted". This means that after the patch is applied, no >> behavioral changes exists for whoever is still using memcg to control >> their memory usage. >> >> We always account to both user and kernel resource_counters. This >> effectively means that an independent kernel limit is in place when the >> limit is set to a lower value than the user memory. A equal or higher >> value means that the user limit will always hit first, meaning that kmem >> is effectively unlimited. >> >> People who want to track kernel memory but not limit it, can set this >> limit to a very high number (like RESOURCE_MAX - 1page - that no one >> will ever hit, or equal to the user memory) >> >> Signed-off-by: Glauber Costa >> CC: Michal Hocko >> CC: Johannes Weiner >> Reviewed-by: Kamezawa Hiroyuki > > Could you add a patch for documentation of this new interface and a text > explaining the behavior of "kmem_accounting" ? > > Hm, my concern is the difference of behavior between user page accounting and > kmem accounting...but this is how tcp-accounting is working. > > Once you add Documentation, it's okay to add my Ack. > I plan to add documentation in a separate patch. Due to that, can I add your ack to this patch here? Also, I find that the description text in patch0 grew to be quite informative and complete. I plan to add that to the documentation if that is ok with you