Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752310Ab2EaFC2 (ORCPT ); Thu, 31 May 2012 01:02:28 -0400 Received: from mail-pb0-f46.google.com ([209.85.160.46]:59608 "EHLO mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751304Ab2EaFC0 (ORCPT ); Thu, 31 May 2012 01:02:26 -0400 Date: Wed, 30 May 2012 22:02:23 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Kamezawa Hiroyuki cc: KOSAKI Motohiro , Gao feng , hannes@cmpxchg.org, mhocko@suse.cz, bsingharora@gmail.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, linux-mm@kvack.org, containers@lists.linux-foundation.org Subject: Re: [PATCH] meminfo: show /proc/meminfo base on container's memcg In-Reply-To: <4FC6D881.4090706@jp.fujitsu.com> Message-ID: References: <1338260214-21919-1-git-send-email-gaofeng@cn.fujitsu.com> <4FC6B68C.2070703@jp.fujitsu.com> <4FC6BC3E.5010807@jp.fujitsu.com> <4FC6C111.2060108@jp.fujitsu.com> <4FC6D881.4090706@jp.fujitsu.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1410 Lines: 30 On Thu, 31 May 2012, Kamezawa Hiroyuki wrote: > > It's not just a memcg issue, it would also be a cpusets issue. > > I think you can add cpuset.meminfo. > It's simple to find the same information by reading the per-node meminfo files in sysfs for each of the allowed cpuset mems. This is why this approach has been nacked in the past, specifically by Paul Jackson when he implemented cpusets. The bottomline is that /proc/meminfo is one of many global resource state interfaces and doesn't imply that every thread has access to the full resources. It never has. It's very simple for another thread to consume a large amount of memory as soon as your read() of /proc/meminfo completes and then that information is completely bogus. We also don't want to virtualize every single global resource state interface, it would be never ending. Applications that administer memory cgroups or cpusets can get this information very easily, each application within those memory cgroups or cpusets does not need it and should not rely on it: it provides no guarantee about future usage nor notifies the application when the amount of free memory changes. -- 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/