Lines Matching refs:of
19 Benefits and Purpose of the memory controller
21 The memory controller isolates the memory behaviour of a group of tasks
22 from the rest of the system. The article on LWN [12] mentions some probable
23 uses of the memory controller. The memory controller can be used to
25 a. Isolate an application or a group of applications
27 amount of memory.
28 b. Create a cgroup with a limited amount of memory; this can be used
30 c. Virtualization solutions can control the amount of memory they want
32 d. A CD/DVD burner could control the amount of memory used by the
33 rest of the system to ensure that burning does not fail due to lack
34 of available memory.
38 Current Status: linux-2.6.34-mmotm(development version of 2010/April)
55 Brief summary of control files.
57 tasks # attach a task(thread) and show list of threads
58 cgroup.procs # show list of processes
64 memory.limit_in_bytes # set/show limit of memory usage
65 memory.memsw.limit_in_bytes # set/show limit of memory+Swap usage
66 memory.failcnt # show the number of memory usage hits limits
67 memory.memsw.failcnt # show the number of memory+Swap hits limits
70 memory.soft_limit_in_bytes # set/show soft limit of memory usage
75 memory.swappiness # set/show swappiness parameter of vmscan
77 memory.move_charge_at_immigrate # set/show controls of moving charges
79 memory.numa_stat # show the number of memory usage per numa node
83 memory.kmem.failcnt # show the number of kernel memory usage hits limits
88 memory.kmem.tcp.failcnt # show the number of tcp buf memory usage hits limits
95 there were several implementations for memory control. The goal of the
98 in Feb 2007. Pavel Emelianov [3][4][5] has since posted three versions of the
101 to allow user space handling of OOM. The current memory controller is
108 amount. If a task requires a lot of CPU processing, the task can spread
109 its processing over a period of hours, days, months or years, but with
124 The core of the design is a counter called the page_counter. The
125 page_counter tracks the current memory usage and limit of the group of
149 (Figure 1: Hierarchy of Accounting)
152 Figure 1 shows the important aspects of the controller
162 More details can be found in the reclaim section of this document.
175 inserted into inode (radix-tree). While it's mapped into the page tables of
191 of used pages; not-on-LRU pages tend to be out-of-control from VM view.
195 Shared pages are accounted on the basis of the first touch approach. The
205 When you do swapoff and make swapped-out pages of shmem(tmpfs) to
207 caller of swapoff rather than the users of shmem.
218 memsw means memory+swap. Usage of memory+swap is limited by
221 Example: Assume a system with 4G of swap. A task which allocates 6G of memory
223 In this case, setting memsw.limit_in_bytes=3G will prevent bad use of swap.
229 to move account from memory to swap...there is no change in usage of
230 memory+swap. In other words, when we want to limit the usage of swap without
232 an OS point of view.
238 from it for sanity of the system's memory management state. You can't forbid
274 zone->lru_lock, it has no lock of its own.
279 the amount of kernel memory used by the system. Kernel memory is fundamentally
281 possible to DoS the system by consuming too much of this precious resource.
288 automatically be accounted regardless of their limit value.
291 is removed. The memory limitation itself, can of course be removed by writing
312 of each kmem_cache is created every time the cache is touched by the first time
320 per cgroup, instead of globally.
327 never be limited completely independently of user memory. Say "U" is the user
336 Kernel memory is a subset of the user memory. This setup is useful in
337 deployments where the total amount of memory per-cgroup is overcommited.
339 box can still run out of non-reclaimable memory.
340 In this case, the admin could set up K so that the sum of all groups is
341 never greater than the total memory, and freely set U at the cost of his
349 triggered for the cgroup for both kinds of memory. This setup gives the
350 admin a unified view of memory, and it is also useful for people who just
387 A successful write to this file does not guarantee a successful setting of
389 number of factors, such as rounding up to page boundaries or the total
390 availability of memory on the system. The user is required to re-read
397 The memory.failcnt field gives the number of times that the cgroup limit was
400 The memory.stat file gives accounting information. Now, the number of
408 testing on tmpfs will give you good numbers of small overheads.
413 test because it has noise of shared objects/status.
426 A sync followed by echo 1 > /proc/sys/vm/drop_caches will help get rid of
427 some of the pages cached in the cgroup (page cache pages).
439 You can move charges of a task along with task migration.
453 Charges recorded in swap information is not updated at removal of cgroup.
455 will be charged as a new owner of it.
470 Because rmdir() moves all pages to parent, some out-of-use page caches can be
485 cache - # of bytes of page cache memory.
486 rss - # of bytes of anonymous and swap cache memory (includes
488 rss_huge - # of bytes of anonymous transparent hugepages.
489 mapped_file - # of bytes of mapped file (includes tmpfs/shmem)
490 pgpgin - # of charging events to the memory cgroup. The charging
493 pgpgout - # of uncharging events to the memory cgroup. The uncharging
495 swap - # of bytes of swap usage
496 dirty - # of bytes that are waiting to get written back to the disk.
497 writeback - # of bytes of file/anon cache that are queued for syncing to
499 inactive_anon - # of bytes of anonymous and swap cache memory on inactive
501 active_anon - # of bytes of anonymous and swap cache memory on active
503 inactive_file - # of bytes of file-backed memory on inactive LRU list.
504 active_file - # of bytes of file-backed memory on active LRU list.
505 unevictable - # of bytes of memory that cannot be reclaimed (mlocked etc).
509 hierarchical_memory_limit - # of bytes of memory limit with regard to hierarchy
511 hierarchical_memsw_limit - # of bytes of memory+swap limit with regard to
514 total_<counter> - # hierarchical version of <counter>, which in
516 sum of all hierarchical children's values of
527 recent_rotated means recent frequency of LRU rotation.
528 recent_scanned means recent # of scans to LRU.
532 Only anonymous and swap cache memory is listed as part of 'rss' stat.
534 amount of physical memory used by the cgroup.
535 'rss + file_mapped" will give you resident set size of cgroup.
537 file_mapped is accounted only when the memory cgroup is owner of page
553 This failcnt(== failure count) shows the number of times that a usage counter
564 method and doesn't show 'exact' value of memory (and swap) usage, it's a fuzz
574 node. One of the use cases is evaluating application performance by
581 The output format of memory.numa_stat is:
589 The "total" count is sum of file + anon + unevictable.
607 usage of e, is accounted to its ancestors up until the root (i.e, c and root),
608 that has memory.use_hierarchy enabled. If one of the ancestors goes over its
610 children of the ancestor.
615 can be enabled by writing 1 to memory.use_hierarchy file of the root cgroup
628 case of an OOM event in any cgroup.
632 Soft limits allow for greater sharing of memory. The idea behind soft limits
633 is to allow control groups to use as much of the memory as needed, provided
639 are pushed back to their soft limits. If the soft limit of each control
641 sure that one control group does not starve the others of memory.
652 assume a soft limit of 256 MiB)
660 NOTE1: Soft limits take effect over a long period of time, since they involve
669 This feature is not supported in !CONFIG_MMU environments because of lack of
675 writing to memory.move_charge_at_immigrate of the destination cgroup.
681 Note: Each bits of move_charge_at_immigrate has its own meaning about what type
682 of charges should be moved. See 8.2 for details.
684 a leader of a thread group.
694 8.2 Type of charges which can be moved
696 Each bit in move_charge_at_immigrate has its own meaning about what type of
697 charges should be moved. But in any case, it must be noted that an account of
701 bit | what type of charges would be moved ?
703 0 | A charge of an anonymous page (or swap of it) used by the target task.
704 | You must enable Swap Extension (see 2.4) to enable move of swap charges.
706 1 | A charge of file pages (normal file, tmpfs file (e.g. ipc shared memory)
707 | and swaps of tmpfs file) mmapped by the target task. Unlike the case of
711 | And mapcount of the page is ignored (the page can be moved even if
713 | enable move of swap charges.
717 - All of moving charge operations are done under cgroup_mutex. It's not good
729 - write string like "<event_fd> <fd of memory.usage_in_bytes> <threshold>" to
748 - write string like "<event_fd> <fd of memory.oom_control>" to
770 At reading, current status of OOM is shown.
779 different strategies of managing their memory resources. The pressure
795 about to out of memory (OOM) or even the in-kernel OOM killer is on its
805 receive it. This is done to avoid excessive "broadcasting" of messages,
816 - write string like "<event_fd> <fd of memory.pressure_level> <level>"
838 (Expect a bunch of notifications, and eventually, the oom-killer will