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 writeback - # of bytes of file/anon cache that are queued for syncing to
498 inactive_anon - # of bytes of anonymous and swap cache memory on inactive
500 active_anon - # of bytes of anonymous and swap cache memory on active
502 inactive_file - # of bytes of file-backed memory on inactive LRU list.
503 active_file - # of bytes of file-backed memory on active LRU list.
504 unevictable - # of bytes of memory that cannot be reclaimed (mlocked etc).
508 hierarchical_memory_limit - # of bytes of memory limit with regard to hierarchy
510 hierarchical_memsw_limit - # of bytes of memory+swap limit with regard to
513 total_<counter> - # hierarchical version of <counter>, which in
515 sum of all hierarchical children's values of
526 recent_rotated means recent frequency of LRU rotation.
527 recent_scanned means recent # of scans to LRU.
531 Only anonymous and swap cache memory is listed as part of 'rss' stat.
533 amount of physical memory used by the cgroup.
534 'rss + file_mapped" will give you resident set size of cgroup.
536 file_mapped is accounted only when the memory cgroup is owner of page
552 This failcnt(== failure count) shows the number of times that a usage counter
563 method and doesn't show 'exact' value of memory (and swap) usage, it's a fuzz
573 node. One of the use cases is evaluating application performance by
580 The output format of memory.numa_stat is:
588 The "total" count is sum of file + anon + unevictable.
606 usage of e, is accounted to its ancestors up until the root (i.e, c and root),
607 that has memory.use_hierarchy enabled. If one of the ancestors goes over its
609 children of the ancestor.
614 can be enabled by writing 1 to memory.use_hierarchy file of the root cgroup
627 case of an OOM event in any cgroup.
631 Soft limits allow for greater sharing of memory. The idea behind soft limits
632 is to allow control groups to use as much of the memory as needed, provided
638 are pushed back to their soft limits. If the soft limit of each control
640 sure that one control group does not starve the others of memory.
651 assume a soft limit of 256 MiB)
659 NOTE1: Soft limits take effect over a long period of time, since they involve
668 This feature is not supported in !CONFIG_MMU environments because of lack of
674 writing to memory.move_charge_at_immigrate of the destination cgroup.
680 Note: Each bits of move_charge_at_immigrate has its own meaning about what type
681 of charges should be moved. See 8.2 for details.
683 a leader of a thread group.
693 8.2 Type of charges which can be moved
695 Each bit in move_charge_at_immigrate has its own meaning about what type of
696 charges should be moved. But in any case, it must be noted that an account of
700 bit | what type of charges would be moved ?
702 0 | A charge of an anonymous page (or swap of it) used by the target task.
703 | You must enable Swap Extension (see 2.4) to enable move of swap charges.
705 1 | A charge of file pages (normal file, tmpfs file (e.g. ipc shared memory)
706 | and swaps of tmpfs file) mmapped by the target task. Unlike the case of
710 | And mapcount of the page is ignored (the page can be moved even if
712 | enable move of swap charges.
716 - All of moving charge operations are done under cgroup_mutex. It's not good
728 - write string like "<event_fd> <fd of memory.usage_in_bytes> <threshold>" to
747 - write string like "<event_fd> <fd of memory.oom_control>" to
769 At reading, current status of OOM is shown.
778 different strategies of managing their memory resources. The pressure
794 about to out of memory (OOM) or even the in-kernel OOM killer is on its
804 receive it. This is done to avoid excessive "broadcasting" of messages,
815 - write string like "<event_fd> <fd of memory.pressure_level> <level>"
837 (Expect a bunch of notifications, and eventually, the oom-killer will