summaryrefslogtreecommitdiffstats
path: root/lib/assoc_array.c
diff options
context:
space:
mode:
authorYu Zhao <yuzhao@google.com>2022-12-22 05:19:05 +0100
committerAndrew Morton <akpm@linux-foundation.org>2023-01-19 02:12:49 +0100
commite9d4e1ee788097484606c32122f146d802a9c5fb (patch)
treefa14d6e3cde63f574f5b66ef5abfea842ef2fcd7 /lib/assoc_array.c
parentmm: multi-gen LRU: per-node lru_gen_folio lists (diff)
downloadlinux-e9d4e1ee788097484606c32122f146d802a9c5fb.tar.xz
linux-e9d4e1ee788097484606c32122f146d802a9c5fb.zip
mm: multi-gen LRU: clarify scan_control flags
Among the flags in scan_control: 1. sc->may_swap, which indicates swap constraint due to memsw.max, is supported as usual. 2. sc->proactive, which indicates reclaim by memory.reclaim, may not opportunistically skip the aging path, since it is considered less latency sensitive. 3. !(sc->gfp_mask & __GFP_IO), which indicates IO constraint, lowers swappiness to prioritize file LRU, since clean file folios are more likely to exist. 4. sc->may_writepage and sc->may_unmap, which indicates opportunistic reclaim, are rejected, since unmapped clean folios are already prioritized. Scanning for more of them is likely futile and can cause high reclaim latency when there is a large number of memcgs. The rest are handled by the existing code. Link: https://lkml.kernel.org/r/20221222041905.2431096-8-yuzhao@google.com Signed-off-by: Yu Zhao <yuzhao@google.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Michael Larabel <Michael@MichaelLarabel.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: Mike Rapoport <rppt@kernel.org> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Suren Baghdasaryan <surenb@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Diffstat (limited to 'lib/assoc_array.c')
0 files changed, 0 insertions, 0 deletions