← Back to branch summary

~ubuntu-branches/ubuntu/precise/linux-ti-omap4/precise

« back to all changes in this revision

Viewing changes to Documentation/cgroups/memory.txt

  • Committer: Bazaar Package Importer
  • Author(s): Paolo Pisati
  • Date: 2011-06-29 15:23:51 UTC
  • mfrom: (26.1.1 natty-proposed)
  • Revision ID: james.westby@ubuntu.com-20110629152351-xs96tm303d95rpbk
Tags: 3.0.0-1200.2
* Rebased against 3.0.0-6.7
* BSP from TI based on 3.0.0

Show diffs side-by-side

added added

removed removed

Lines of Context:
Documentation/cgroups/memory.txt
1
1
Memory Resource Controller
2
2
 
3
 
NOTE: The Memory Resource Controller has been generically been referred
4
 
      to as the memory controller in this document. Do not confuse memory
5
 
      controller used here with the memory controller that is used in hardware.
 
3
NOTE: The Memory Resource Controller has generically been referred to as the
 
4
      memory controller in this document. Do not confuse memory controller
 
5
      used here with the memory controller that is used in hardware.
6
6
 
7
7
(For editors)
8
8
In this document:
52
52
 tasks                           # attach a task(thread) and show list of threads
53
53
 cgroup.procs                    # show list of processes
54
54
 cgroup.event_control            # an interface for event_fd()
55
 
 memory.usage_in_bytes           # show current memory(RSS+Cache) usage.
56
 
 memory.memsw.usage_in_bytes     # show current memory+Swap usage
 
55
 memory.usage_in_bytes           # show current res_counter usage for memory
 
56
                                 (See 5.5 for details)
 
57
 memory.memsw.usage_in_bytes     # show current res_counter usage for memory+Swap
 
58
                                 (See 5.5 for details)
57
59
 memory.limit_in_bytes           # set/show limit of memory usage
58
60
 memory.memsw.limit_in_bytes     # set/show limit of memory+Swap usage
59
61
 memory.failcnt                  # show the number of memory usage hits limits
68
70
                                 (See sysctl's vm.swappiness)
69
71
 memory.move_charge_at_immigrate # set/show controls of moving charges
70
72
 memory.oom_control              # set/show oom controls.
 
73
 memory.numa_stat                # show the number of memory usage per numa node
71
74
 
72
75
1. History
73
76
 
179
182
page will eventually get charged for it (once it is uncharged from
180
183
the cgroup that brought it in -- this will happen on memory pressure).
181
184
 
182
 
Exception: If CONFIG_CGROUP_CGROUP_MEM_RES_CTLR_SWAP is not used..
 
185
Exception: If CONFIG_CGROUP_CGROUP_MEM_RES_CTLR_SWAP is not used.
183
186
When you do swapoff and make swapped-out pages of shmem(tmpfs) to
184
187
be backed into memory in force, charges for pages are accounted against the
185
188
caller of swapoff rather than the users of shmem.
211
214
OS point of view.
212
215
 
213
216
* What happens when a cgroup hits memory.memsw.limit_in_bytes
214
 
When a cgroup his memory.memsw.limit_in_bytes, it's useless to do swap-out
 
217
When a cgroup hits memory.memsw.limit_in_bytes, it's useless to do swap-out
215
218
in this cgroup. Then, swap-out will not be done by cgroup routine and file
216
219
caches are dropped. But as mentioned above, global LRU can do swapout memory
217
220
from it for sanity of the system's memory management state. You can't forbid
261
264
c. Enable CONFIG_CGROUP_MEM_RES_CTLR
262
265
d. Enable CONFIG_CGROUP_MEM_RES_CTLR_SWAP (to use swap extension)
263
266
 
264
 
1. Prepare the cgroups
265
 
# mkdir -p /cgroups
266
 
# mount -t cgroup none /cgroups -o memory
 
267
1. Prepare the cgroups (see cgroups.txt, Why are cgroups needed?)
 
268
# mount -t tmpfs none /sys/fs/cgroup
 
269
# mkdir /sys/fs/cgroup/memory
 
270
# mount -t cgroup none /sys/fs/cgroup/memory -o memory
267
271
 
268
272
2. Make the new group and move bash into it
269
 
# mkdir /cgroups/0
270
 
# echo $$ > /cgroups/0/tasks
 
273
# mkdir /sys/fs/cgroup/memory/0
 
274
# echo $$ > /sys/fs/cgroup/memory/0/tasks
271
275
 
272
276
Since now we're in the 0 cgroup, we can alter the memory limit:
273
 
# echo 4M > /cgroups/0/memory.limit_in_bytes
 
277
# echo 4M > /sys/fs/cgroup/memory/0/memory.limit_in_bytes
274
278
 
275
279
NOTE: We can use a suffix (k, K, m, M, g or G) to indicate values in kilo,
276
280
mega or gigabytes. (Here, Kilo, Mega, Giga are Kibibytes, Mebibytes, Gibibytes.)
278
282
NOTE: We can write "-1" to reset the *.limit_in_bytes(unlimited).
279
283
NOTE: We cannot set limits on the root cgroup any more.
280
284
 
281
 
# cat /cgroups/0/memory.limit_in_bytes
 
285
# cat /sys/fs/cgroup/memory/0/memory.limit_in_bytes
282
286
4194304
283
287
 
284
288
We can check the usage:
285
 
# cat /cgroups/0/memory.usage_in_bytes
 
289
# cat /sys/fs/cgroup/memory/0/memory.usage_in_bytes
286
290
1216512
287
291
 
288
292
A successful write to this file does not guarantee a successful set of
453
457
You can reset failcnt by writing 0 to failcnt file.
454
458
# echo 0 > .../memory.failcnt
455
459
 
 
460
5.5 usage_in_bytes
 
461
 
 
462
For efficiency, as other kernel components, memory cgroup uses some optimization
 
463
to avoid unnecessary cacheline false sharing. usage_in_bytes is affected by the
 
464
method and doesn't show 'exact' value of memory(and swap) usage, it's an fuzz
 
465
value for efficient access. (Of course, when necessary, it's synchronized.)
 
466
If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP)
 
467
value in memory.stat(see 5.2).
 
468
 
 
469
5.6 numa_stat
 
470
 
 
471
This is similar to numa_maps but operates on a per-memcg basis.  This is
 
472
useful for providing visibility into the numa locality information within
 
473
an memcg since the pages are allowed to be allocated from any physical
 
474
node.  One of the usecases is evaluating application performance by
 
475
combining this information with the application's cpu allocation.
 
476
 
 
477
We export "total", "file", "anon" and "unevictable" pages per-node for
 
478
each memcg.  The ouput format of memory.numa_stat is:
 
479
 
 
480
total=<total pages> N0=<node 0 pages> N1=<node 1 pages> ...
 
481
file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ...
 
482
anon=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
 
483
unevictable=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
 
484
 
 
485
And we have total = file + anon + unevictable.
 
486
 
456
487
6. Hierarchy support
457
488
 
458
489
The memory controller supports a deep hierarchy and hierarchical accounting.
460
491
cgroup filesystem. Consider for example, the following cgroup filesystem
461
492
hierarchy
462
493
 
463
 
                root
 
494
               root
464
495
             /  |   \
465
 
           /    |    \
466
 
          a     b       c
467
 
                        | \
468
 
                        |  \
469
 
                        d   e
 
496
            /   |    \
 
497
           a    b     c
 
498
                      | \
 
499
                      |  \
 
500
                      d   e
470
501
 
471
502
In the diagram above, with hierarchical accounting enabled, all memory
472
503
usage of e, is accounted to its ancestors up until the root (i.e, c and root),
485
516
 
486
517
# echo 0 > memory.use_hierarchy
487
518
 
488
 
NOTE1: Enabling/disabling will fail if the cgroup already has other
489
 
       cgroups created below it.
 
519
NOTE1: Enabling/disabling will fail if either the cgroup already has other
 
520
       cgroups created below it, or if the parent cgroup has use_hierarchy
 
521
       enabled.
490
522
 
491
523
NOTE2: When panic_on_oom is set to "2", the whole system will panic in
492
524
       case of an OOM event in any cgroup.