From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [PATCH 09/23] kmem slab accounting basic infrastructure Date: Wed, 25 Apr 2012 11:38:57 -0300 Message-ID: <4F980C81.5060802@parallels.com> References: <1334959051-18203-1-git-send-email-glommer@parallels.com> <1334959051-18203-10-git-send-email-glommer@parallels.com> <4F975430.4090107@jp.fujitsu.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4F975430.4090107@jp.fujitsu.com> Sender: owner-linux-mm@kvack.org List-ID: Content-Type: text/plain; charset="us-ascii" To: KAMEZAWA Hiroyuki Cc: cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, devel@openvz.org, Michal Hocko , Johannes Weiner , Frederic Weisbecker , Greg Thelen , Suleiman Souhlal On 04/24/2012 10:32 PM, KAMEZAWA Hiroyuki wrote: > (2012/04/21 6:57), 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. >> > > Hmm, res_counter never goes naeative ? Why would it? This one has more or less the same logic as the sock buffers. If we are not accounted, the caches don't get created. If the caches don't get created, we don't release them. (this is modulo bugs, of course) -- 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