admin-guide/cgroup-v1/memory.rst

103                                      do file will not have any effect same as if
213 Some pages which are never reclaimable and will not be on the LRU
217 for earlier. A file page will be accounted for as Page Cache when it's
228 Since page's memcg recorded into swap whatever memsw enabled, the page will
242 page will eventually get charged for it (once it is uncharged from
243 the cgroup that brought it in -- this will happen on memory pressure).
260 (by mistake) under 2G memory limitation will use all swap.
261 In this case, setting memsw.limit_in_bytes=3G will prevent bad use of swap.
278 in this cgroup. Then, swap-out will not be done by cgroup routine and file
302    When panic_on_oom is set to "2", the whole system will panic.
304 When oom event notifier is registered, event will be delivered.
334 at boot time. In this case, kernel memory will not be accounted at all.
341 The main "kmem" counter is fed into the main counter, so kmem charges will
393        In the current implementation, memory reclaim will NOT be triggered for
398     Since kmem charges will also be fed to the user counter and reclaim will be
469 testing on tmpfs will give you good numbers of small overheads.
490 A sync followed by echo 1 > /proc/sys/vm/drop_caches will help get rid of
494 <cgroup-v1-memory-oom-control>` (below) and seeing what happens will be
524 will be charged as a new owner of it.
536   the cgroup will be reclaimed and as many pages reclaimed as possible.
541   memory pressure happens. If you want to avoid that, force_empty will be useful.
611 	'rss + mapped_file" will give you resident set size of cgroup.
638 memory under it will be reclaimed.
702 accounting is deprecated. An attempt to do it will result in a failure
705 For compatibility reasons writing 1 to memory.use_hierarchy will always pass::
749        otherwise the hard limit will take precedence.
758 Reading memory.move_charge_at_immigrate will always return 0 and writing
759 to it will always return -EINVAL.
775 Application will be notified through eventfd when memory usage crosses
800 The application will be notified through eventfd when OOM happens.
807 If OOM-killer is disabled, tasks under cgroup will hang/sleep
820 Then, stopped tasks will work again.
863 experiences some pressure. In this situation, only group C will receive the
864 notification, i.e. groups A and B will not receive it. This is done to avoid
866 especially bad if we are low on memory or thrashing. Group B, will receive
878    example, groups A, B, and C will receive notification of memory pressure.
882    registered. In the above example, group C will receive notification if
884    pressure. However, group B will never receive notification, regardless if
902 Application will be notified through eventfd when memory pressure is at
921    (Expect a bunch of notifications, and eventually, the oom-killer will