On Thu, 31 May 2012, Kamezawa Hiroyuki wrote:

quoted

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, 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>