Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933603Ab2JLI1f (ORCPT ); Fri, 12 Oct 2012 04:27:35 -0400 Received: from cantor2.suse.de ([195.135.220.15]:34325 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933255Ab2JLI1c (ORCPT ); Fri, 12 Oct 2012 04:27:32 -0400 Date: Fri, 12 Oct 2012 10:27:28 +0200 From: Michal Hocko To: Glauber Costa Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Mel Gorman , Suleiman Souhlal , Tejun Heo , cgroups@vger.kernel.org, kamezawa.hiroyu@jp.fujitsu.com, Johannes Weiner , Greg Thelen , devel@openvz.org, Frederic Weisbecker Subject: Re: [PATCH v4 04/14] kmem accounting basic infrastructure Message-ID: <20121012082728.GC10110@dhcp22.suse.cz> References: <1349690780-15988-1-git-send-email-glommer@parallels.com> <1349690780-15988-5-git-send-email-glommer@parallels.com> <20121011101119.GB29295@dhcp22.suse.cz> <5077C886.2030609@parallels.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5077C886.2030609@parallels.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2050 Lines: 56 On Fri 12-10-12 11:36:38, Glauber Costa wrote: > On 10/11/2012 02:11 PM, Michal Hocko wrote: > > On Mon 08-10-12 14:06:10, Glauber Costa wrote: [...] > >> + if (!memcg->kmem_accounted && val != RESOURCE_MAX) { > > > > Just a nit but wouldn't memcg_kmem_is_accounted(memcg) be better than > > directly checking kmem_accounted? > > Besides that I am not sure I fully understand RESOURCE_MAX test. Say I > > want to have kmem accounting for monitoring so I do > > echo -1 > memory.kmem.limit_in_bytes > > > > so you set the value but do not activate it. Isn't this just a reminder > > from the time when the accounting could be deactivated? > > > > No, not at all. > > I see you have talked about that in other e-mails, (I was on sick leave > yesterday), so let me consolidate it all here: > > What we discussed before, regarding to echo -1 > ... was around the > disable code, something that we no longer allow. So now, if you will > echo -1 to that file *after* it is limited, you get in track only mode. > > But for you to start that, you absolutely have to write something > different than -1. > > Just one example: libcgroup, regardless of how lame we think it is in > this regard, will write to all cgroup files by default when a file is > updated. If you haven't written anything, it will still write the same > value that the file had before. Ohh, I wasn't aware of that and it sounds pretty lame. > This means that an already deployed libcg-managed installation will > suddenly enable kmem for every cgroup. Sure this can be fixed in > userspace, but: > > 1) There is no reason to break it, if we can You are right > 2) It is perfectly reasonable to expect that if you write to a file the > same value that was already there, nothing happens. Fair enough -- Michal Hocko SUSE Labs -- 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/