Re: About cgroup memory limits

From: KAMEZAWA Hiroyuki
Date: Thu May 10 2012 - 05:49:18 EST


(2012/05/10 3:37), Andre Nathan wrote:

> Hello
>
> I'm doing some tests with LXC and how it interacts with the memory
> cgroup limits, more specifically the memory.limit_in_bytes control file.
>
> Am I correct in my understanding of the memory cgroup documentation[1]
> that the limit set in memory.limit_in_bytes is applied to the sum of the
> fields 'cache', 'rss' and 'mapped_file' in the memory.stat file?
>

cache includes mapped_file. Then,

rss + cache < limit.

cache - mapped_file == unmapped file caches.


> I am also trying to understand the values reported in memory.stat when
> compared to the statistics in /proc/$PID/statm.
>
> Below is the sum of each field in /proc/$PID/statm for every process
> running inside a test container, converted to bytes:
>
> size resident share text lib data dt
> 897208320 28741632 20500480 1171456 0 170676224 0
>

from statm source code.

size = total virtual memory size
# total amount of mmaps().

shared = mapped_file
# resident mapped file caches

text = end_code - start_code
# end_code and start_code is determined when the program is loaded.
# this is virtual memory size.

data = total virtual memory size - MAP_SHARED virtual memory size.

regisdent = anonymous pages + mapped_file.


> Compare this with the usage reports from memory.stat (fields total_*,
> hierarchical_* and pg* omitted):
>
> cache 16834560
> rss 8192000
> mapped_file 3743744
> swap 0
> inactive_anon 0
> active_anon 8192000
> inactive_file 13996032
> active_file 2838528
> unevictable 0
>
> Is there a way to reconcile these numbers somehow? I understand that the
> fields from the two files represent different things. What I'm trying to
> do is to combine, for example, the fields from memory.stat to
> approximately reach what is displayed by statm.
>


>From above, rss + mapped_file == resident.

Thanks,
-Kame


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/