[PATCH v2 0/2] reclaim contended folios asynchronously instead of promoting them

lipeifeng@oppo.com posted 2 patches 1 year, 11 months ago
include/linux/mmzone.h        |   6 +
include/linux/rmap.h          |   5 +-
include/linux/swap.h          |   3 +
include/linux/vm_event_item.h |   2 +
mm/memory_hotplug.c           |   2 +
mm/rmap.c                     |   5 +-
mm/vmscan.c                   | 205 +++++++++++++++++++++++++++++++++-
mm/vmstat.c                   |   2 +
8 files changed, 221 insertions(+), 9 deletions(-)
[PATCH v2 0/2] reclaim contended folios asynchronously instead of promoting them
Posted by lipeifeng@oppo.com 1 year, 11 months ago
From: Peifeng Li <lipeifeng@oppo.com>

Commit 6d4675e60135 ("mm: don't be stuck to rmap lock on reclaim path")
prevents the reclaim path from becoming stuck on the rmap lock. However,
it reinserts those folios at the head of the LRU during shrink_folio_list,
even if those folios are very cold.

This can have a detrimental effect on performance by increasing refaults
and the likelihood of OOM (Out of Memory) killing.

This patchset introduces a new kthread:kshrinkd thread to asynchronously
reclaim contended folios rather than promoting them, thereby preventing
excessive violations of LRU rules. We observed a noticeable decrease in
refaults and OOM killing as a result.

-v2:
  * rewrite the commit messages;
  * rebase on top of mm-unstable
-v1:
  https://lore.kernel.org/linux-mm/20240219141703.3851-1-lipeifeng@oppo.com/

Peifeng Li (2):
  mm/rmap: provide folio_referenced with the options to try_lock or lock
  mm: vmscan: reclaim contended folios asynchronously instead of
    promoting them

 include/linux/mmzone.h        |   6 +
 include/linux/rmap.h          |   5 +-
 include/linux/swap.h          |   3 +
 include/linux/vm_event_item.h |   2 +
 mm/memory_hotplug.c           |   2 +
 mm/rmap.c                     |   5 +-
 mm/vmscan.c                   | 205 +++++++++++++++++++++++++++++++++-
 mm/vmstat.c                   |   2 +
 8 files changed, 221 insertions(+), 9 deletions(-)

-- 
2.34.1
Re: [PATCH v2 0/2] reclaim contended folios asynchronously instead of promoting them
Posted by Matthew Wilcox 1 year, 11 months ago
On Fri, Mar 08, 2024 at 11:11:24AM +0800, lipeifeng@oppo.com wrote:
> Commit 6d4675e60135 ("mm: don't be stuck to rmap lock on reclaim path")
> prevents the reclaim path from becoming stuck on the rmap lock. However,
> it reinserts those folios at the head of the LRU during shrink_folio_list,
> even if those folios are very cold.

This seems like a lot of new code.  Did you consider something simpler
like this?

Also, this is Minchan's patch you're complaining about.  Add him to the
cc.

+++ b/mm/vmscan.c
@@ -817,6 +817,7 @@ enum folio_references {
        FOLIOREF_RECLAIM,
        FOLIOREF_RECLAIM_CLEAN,
        FOLIOREF_KEEP,
+       FOLIOREF_RESCAN,
        FOLIOREF_ACTIVATE,
 };

@@ -837,9 +838,9 @@ static enum folio_references folio_check_references(struct folio *folio,
        if (vm_flags & VM_LOCKED)
                return FOLIOREF_ACTIVATE;

-       /* rmap lock contention: rotate */
+       /* rmap lock contention: keep at the tail */
        if (referenced_ptes == -1)
-               return FOLIOREF_KEEP;
+               return FOLIOREF_RESCAN;

        if (referenced_ptes) {
                /*
@@ -1164,6 +1165,7 @@ static unsigned int shrink_folio_list(struct list_head *folio_list,
                case FOLIOREF_ACTIVATE:
                        goto activate_locked;
                case FOLIOREF_KEEP:
+               case FOLIOREF_RESCAN:
                        stat->nr_ref_keep += nr_pages;
                        goto keep_locked;
                case FOLIOREF_RECLAIM:
@@ -1446,7 +1448,10 @@ static unsigned int shrink_folio_list(struct list_head *folio_list,
 keep_locked:
                folio_unlock(folio);
 keep:
-               list_add(&folio->lru, &ret_folios);
+               if (references == FOLIOREF_RESCAN)
+                       list_add(&folio->lru, &rescan_folios);
+               else
+                       list_add(&folio->lru, &ret_folios);
                VM_BUG_ON_FOLIO(folio_test_lru(folio) ||
                                folio_test_unevictable(folio), folio);
        }