Lines Matching full:will

190 Some pages which are never reclaimable and will not be on the LRU
194 for earlier. A file page will be accounted for as Page Cache when it's
205 Since page's memcg recorded into swap whatever memsw enabled, the page will
219 page will eventually get charged for it (once it is uncharged from
220 the cgroup that brought it in -- this will happen on memory pressure).
240 (by mistake) under 2G memory limitation will use all swap.
241 In this case, setting memsw.limit_in_bytes=3G will prevent bad use of swap.
256 in this cgroup. Then, swap-out will not be done by cgroup routine and file
280   When panic_on_oom is set to "2", the whole system will panic.
282 When oom event notifier is registered, event will be delivered.
313 at boot time. In this case, kernel memory will not be accounted at all.
320 The main "kmem" counter is fed into the main counter, so kmem charges will
372     In the current implementation, memory reclaim will NOT be
377     Since kmem charges will also be fed to the user counter and reclaim will be
454 testing on tmpfs will give you good numbers of small overheads.
473 A sync followed by echo 1 > /proc/sys/vm/drop_caches will help get rid of
477 seeing what happens will be helpful.
504 will be charged as a new owner of it.
518   the cgroup will be reclaimed and as many pages reclaimed as possible.
523   memory pressure happens. If you want to avoid that, force_empty will be useful.
526   kernel pages will still be seen. This is not considered a failure and the
527   write will still return success. In this case, it is expected that
599 	'rss + mapped_file" will give you resident set size of cgroup.
622 memory under it will be reclaimed.
696        Enabling/disabling will fail if either the cgroup already has other
701        When panic_on_oom is set to "2", the whole system will panic in
741        otherwise the hard limit will take precedence.
795 |   | will be moved even if the task hasn't done page fault, i.e. they might   |
822 Application will be notified through eventfd when memory usage crosses
843 The application will be notified through eventfd when OOM happens.
850 If OOM-killer is disabled, tasks under cgroup will hang/sleep
863 Then, stopped tasks will work again.
901 experiences some pressure. In this situation, only group C will receive the
902 notification, i.e. groups A and B will not receive it. This is done to avoid
904 especially bad if we are low on memory or thrashing. Group B, will receive
916    example, groups A, B, and C will receive notification of memory pressure.
920    registered. In the above example, group C will receive notification if
922    pressure. However, group B will never receive notification, regardless if
940 Application will be notified through eventfd when memory pressure is at
959    (Expect a bunch of notifications, and eventually, the oom-killer will