On Tue, Feb 28, 2023 at 12:50 AM Yosry Ahmed <yosryahmed@xxxxxxxxxx> wrote: > > Reclaimed pages through other means than LRU-based reclaim are tracked > through reclaim_state in struct scan_control, which is stashed in > current task_struct. These pages are added to the number of reclaimed > pages through LRUs. For memcg reclaim, these pages generally cannot be > linked to the memcg under reclaim and can cause an overestimated count > of reclaimed pages. This short series tries to address that. > > Patch 1 is just refactoring updating reclaim_state into a helper > function, and renames reclaimed_slab to just reclaimed, with a comment > describing its true purpose. > > Patch 2 ignores pages reclaimed outside of LRU reclaim in memcg reclaim. > The pages are uncharged anyway, so even if we end up under-reporting > reclaimed pages we will still succeed in making progress during > charging. > > Do not let the diff stat trick you, patch 2 is a one-line change. All > the rest is moving a couple of functions around and a huge comment :) > > RFC -> v1: > - Exported report_freed_pages in case XFS is built as a module (Matthew > Wilcox). > - Renamed reclaimed_slab to reclaim in previously missed MGLRU code. > - Refactored using reclaim_state to update sc->nr_reclaimed into a > helper and added an XL comment explaining why we ignore > reclaim_state->reclaimed in memcg reclaim (Johannes Weiner). > > Yosry Ahmed (2): > mm: vmscan: refactor updating reclaimed pages in reclaim_state > mm: vmscan: ignore non-LRU-based reclaim in memcg reclaim > > fs/inode.c | 3 +- > fs/xfs/xfs_buf.c | 3 +- > include/linux/swap.h | 5 ++- > mm/slab.c | 3 +- > mm/slob.c | 6 ++-- > mm/slub.c | 5 ++- > mm/vmscan.c | 79 +++++++++++++++++++++++++++++++++++--------- > 7 files changed, 74 insertions(+), 30 deletions(-) > > -- > 2.39.2.722.g9855ee24e9-goog > Friendly ping on this series, any comments or thoughts -- especially on the memcg side?
