Commit 50c35e5b authored by Ying Han's avatar Ying Han Committed by Linus Torvalds

memcg: add documentation for the memory.numastat API

[akpm@linux-foundation.org: rework text, fit it into 80-cols]
Signed-off-by: default avatarYing Han <yinghan@google.com>
Reviewed-by: default avatarKOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: default avatarBalbir Singh <bsingharora@gmail.com>
Acked-by: default avatarKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
parent d7911ef3
...@@ -70,6 +70,7 @@ Brief summary of control files. ...@@ -70,6 +70,7 @@ Brief summary of control files.
(See sysctl's vm.swappiness) (See sysctl's vm.swappiness)
memory.move_charge_at_immigrate # set/show controls of moving charges memory.move_charge_at_immigrate # set/show controls of moving charges
memory.oom_control # set/show oom controls. memory.oom_control # set/show oom controls.
memory.numa_stat # show the number of memory usage per numa node
1. History 1. History
...@@ -464,6 +465,24 @@ value for efficient access. (Of course, when necessary, it's synchronized.) ...@@ -464,6 +465,24 @@ value for efficient access. (Of course, when necessary, it's synchronized.)
If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP) If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP)
value in memory.stat(see 5.2). value in memory.stat(see 5.2).
5.6 numa_stat
This is similar to numa_maps but operates on a per-memcg basis. This is
useful for providing visibility into the numa locality information within
an memcg since the pages are allowed to be allocated from any physical
node. One of the usecases is evaluating application performance by
combining this information with the application's cpu allocation.
We export "total", "file", "anon" and "unevictable" pages per-node for
each memcg. The ouput format of memory.numa_stat is:
total=<total pages> N0=<node 0 pages> N1=<node 1 pages> ...
file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ...
anon=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
unevictable=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
And we have total = file + anon + unevictable.
6. Hierarchy support 6. Hierarchy support
The memory controller supports a deep hierarchy and hierarchical accounting. The memory controller supports a deep hierarchy and hierarchical accounting.
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment