[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240308031126.750-1-lipeifeng@oppo.com>
Date: Fri, 8 Mar 2024 11:11:24 +0800
From: lipeifeng@...o.com
To: lipeifeng@...o.com,
21cnbao@...il.com,
akpm@...ux-foundation.org,
david@...hat.com,
osalvador@...e.de,
willy@...radead.org
Cc: linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: [PATCH v2 0/2] reclaim contended folios asynchronously instead of promoting them
From: Peifeng Li <lipeifeng@...o.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
Powered by blists - more mailing lists