[PATCH v2 1/3] mm-unstable: Multi-gen LRU: Fix per-zone reclaim

[PATCH v2 1/3] mm-unstable: Multi-gen LRU: Fix per-zone reclaim

[Kalesh Singh]

MGLRU has a LRU list for each zone for each type (anon/file) in each
generation:

	long nr_pages[MAX_NR_GENS][ANON_AND_FILE][MAX_NR_ZONES];
The min_seq (oldest generation) can progress independently for each
type but the max_seq (youngest generation) is shared for both anon and
file. This is to maintain a common frame of reference.

In order for eviction to advance the min_seq of a type, all the per-zone
lists in the oldest generation of that type must be empty.

The eviction logic only considers pages from eligible zones for
eviction or promotion.

    scan_folios() {
	...
	for (zone = sc->reclaim_idx; zone >= 0; zone--)  {
	    ...
	    sort_folio(); 	// Promote
	    ...
	    isolate_folio(); 	// Evict
	}
	...
    }

Consider the system has the movable zone configured and default 4
generations. The current state of the system is as shown below
(only illustrating one type for simplicity):

Type: ANON

	Zone    DMA32     Normal    Movable    Device

	Gen 0       0          0        4GB         0

	Gen 1       0        1GB        1MB         0

	Gen 2     1MB        4GB        1MB         0

	Gen 3     1MB        1MB        1MB         0

Now consider there is a GFP_KERNEL allocation request (eligible zone
index <= Normal), evict_folios() will return without doing any work
since there are no pages to scan in the eligible zones of the oldest
generation. Reclaim won't make progress until triggered from a ZONE_MOVABLE
allocation request; which may not happen soon if there is a lot of free
memory in the movable zone. This can lead to OOM kills, although there
is 1GB pages in the Normal zone of Gen 1 that we have not yet tried to
reclaim.

This issue is not seen in the conventional active/inactive LRU since
there are no per-zone lists.

If there are no (not enough) folios to scan in the eligible zones, move
folios from ineligible zone (zone_index > reclaim_index) to the next
generation. This allows for the progression of min_seq and reclaiming
from the next generation (Gen 1).

Qualcomm, Mediatek and raspberrypi [1] discovered this issue independently.

[1] https://github.com/raspberrypi/linux/issues/5395

Fixes: ac35a4902374 ("mm: multi-gen LRU: minimal implementation")
Cc: stable@vger.kernel.org
Cc: Yu Zhao <yuzhao@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Reported-by: Charan Teja Kalla <quic_charante@quicinc.com>
Reported-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
---

Changes in v2:
  - Add Fixes tag and cc stable

 mm/vmscan.c | 18 ++++++++++++++----
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 4039620d30fe..489a4fc7d9b1 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -4889,7 +4889,8 @@ static int lru_gen_memcg_seg(struct lruvec *lruvec)
  *                          the eviction
  ******************************************************************************/
 
-static bool sort_folio(struct lruvec *lruvec, struct folio *folio, int tier_idx)
+static bool sort_folio(struct lruvec *lruvec, struct folio *folio, struct scan_control *sc,
+		       int tier_idx)
 {
 	bool success;
 	int gen = folio_lru_gen(folio);
@@ -4939,6 +4940,13 @@ static bool sort_folio(struct lruvec *lruvec, struct folio *folio, int tier_idx)
 		return true;
 	}
 
+	/* ineligible */
+	if (zone > sc->reclaim_idx) {
+		gen = folio_inc_gen(lruvec, folio, false);
+		list_move_tail(&folio->lru, &lrugen->folios[gen][type][zone]);
+		return true;
+	}
+
 	/* waiting for writeback */
 	if (folio_test_locked(folio) || folio_test_writeback(folio) ||
 	    (type == LRU_GEN_FILE && folio_test_dirty(folio))) {
@@ -4987,7 +4995,8 @@ static bool isolate_folio(struct lruvec *lruvec, struct folio *folio, struct sca
 static int scan_folios(struct lruvec *lruvec, struct scan_control *sc,
 		       int type, int tier, struct list_head *list)
 {
-	int gen, zone;
+	int i;
+	int gen;
 	enum vm_event_item item;
 	int sorted = 0;
 	int scanned = 0;
@@ -5003,9 +5012,10 @@ static int scan_folios(struct lruvec *lruvec, struct scan_control *sc,
 
 	gen = lru_gen_from_seq(lrugen->min_seq[type]);
 
-	for (zone = sc->reclaim_idx; zone >= 0; zone--) {
+	for (i = MAX_NR_ZONES; i > 0; i--) {
 		LIST_HEAD(moved);
 		int skipped = 0;
+		int zone = (sc->reclaim_idx + i) % MAX_NR_ZONES;
 		struct list_head *head = &lrugen->folios[gen][type][zone];
 
 		while (!list_empty(head)) {
@@ -5019,7 +5029,7 @@ static int scan_folios(struct lruvec *lruvec, struct scan_control *sc,
 
 			scanned += delta;
 
-			if (sort_folio(lruvec, folio, tier))
+			if (sort_folio(lruvec, folio, sc, tier))
 				sorted += delta;
 			else if (isolate_folio(lruvec, folio, sc)) {
 				list_add(&folio->lru, list);
-- 
2.41.0.255.g8b1d071c50-goog

[PATCH v2 2/3] mm-unstable: Multi-gen LRU: Avoid race in inc_min_seq()

[Kalesh Singh]

inc_max_seq() will try to inc_min_seq() if nr_gens == MAX_NR_GENS. This
is because the generations are reused (the last oldest now empty
generation will become the next youngest generation).

inc_min_seq() is retried until successful, dropping the lru_lock
and yielding the CPU on each failure, and retaking the lock before
trying again:

        while (!inc_min_seq(lruvec, type, can_swap)) {
                spin_unlock_irq(&lruvec->lru_lock);
                cond_resched();
                spin_lock_irq(&lruvec->lru_lock);
        }

However, the initial condition that required incrementing the min_seq
(nr_gens == MAX_NR_GENS) is not retested. This can change by another
call to inc_max_seq() from run_aging() with force_scan=true from the
debugfs interface.

Since the eviction stalls when the nr_gens == MIN_NR_GENS, avoid
unnecessarily incrementing the min_seq by rechecking the number of
generations before each attempt.

This issue was uncovered in previous discussion on the list by Yu Zhao
and Aneesh Kumar [1].

[1] https://lore.kernel.org/linux-mm/CAOUHufbO7CaVm=xjEb1avDhHVvnC8pJmGyKcFf2iY_dpf+zR3w@mail.gmail.com/

Fixes: d6c3af7d8a2b ("mm: multi-gen LRU: debugfs interface")
Cc: stable@vger.kernel.org
Cc: Yu Zhao <yuzhao@google.com>
Cc: Aneesh Kumar K V <aneesh.kumar@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
---

Changes in v2:
  - Add Fixes tag and cc stable

 mm/vmscan.c | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 489a4fc7d9b1..6eecd291756c 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -4439,7 +4439,7 @@ static void inc_max_seq(struct lruvec *lruvec, bool can_swap, bool force_scan)
 	int prev, next;
 	int type, zone;
 	struct lru_gen_folio *lrugen = &lruvec->lrugen;
-
+restart:
 	spin_lock_irq(&lruvec->lru_lock);
 
 	VM_WARN_ON_ONCE(!seq_is_valid(lruvec));
@@ -4450,11 +4450,12 @@ static void inc_max_seq(struct lruvec *lruvec, bool can_swap, bool force_scan)
 
 		VM_WARN_ON_ONCE(!force_scan && (type == LRU_GEN_FILE || can_swap));
 
-		while (!inc_min_seq(lruvec, type, can_swap)) {
-			spin_unlock_irq(&lruvec->lru_lock);
-			cond_resched();
-			spin_lock_irq(&lruvec->lru_lock);
-		}
+		if (inc_min_seq(lruvec, type, can_swap))
+			continue;
+
+		spin_unlock_irq(&lruvec->lru_lock);
+		cond_resched();
+		goto restart;
 	}
 
 	/*
-- 
2.41.0.255.g8b1d071c50-goog

[PATCH v2 3/3] mm-unstable: Multi-gen LRU: Fix can_swap in lru_gen_look_around()

[Kalesh Singh]

walk->can_swap might be invalid since it's not guaranteed to be
initialized for the particular lruvec. Instead deduce it from the folio
type (anon/file).

Fixes: 018ee47f1489 ("mm: multi-gen LRU: exploit locality in rmap")
Cc: Yu Zhao <yuzhao@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
---

Changes in v2:
  - Add Fixes tag

 mm/vmscan.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 6eecd291756c..b4329f93a682 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -4656,6 +4656,7 @@ void lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
 	pte_t *pte = pvmw->pte;
 	unsigned long addr = pvmw->address;
 	struct folio *folio = pfn_folio(pvmw->pfn);
+	bool can_swap = !folio_is_file_lru(folio);
 	struct mem_cgroup *memcg = folio_memcg(folio);
 	struct pglist_data *pgdat = folio_pgdat(folio);
 	struct lruvec *lruvec = mem_cgroup_lruvec(memcg, pgdat);
@@ -4704,7 +4705,7 @@ void lru_gen_look_around(struct page_vma_mapped_walk *pvmw)
 		if (!pte_young(ptent))
 			continue;
 
-		folio = get_pfn_folio(pfn, memcg, pgdat, !walk || walk->can_swap);
+		folio = get_pfn_folio(pfn, memcg, pgdat, can_swap);
 		if (!folio)
 			continue;
 
-- 
2.41.0.255.g8b1d071c50-goog

Re: [PATCH v2 1/3] mm-unstable: Multi-gen LRU: Fix per-zone reclaim

[AngeloGioacchino Del Regno]

Il 02/08/23 04:56, Kalesh Singh ha scritto:
> MGLRU has a LRU list for each zone for each type (anon/file) in each
> generation:
> 
> 	long nr_pages[MAX_NR_GENS][ANON_AND_FILE][MAX_NR_ZONES];
> The min_seq (oldest generation) can progress independently for each
> type but the max_seq (youngest generation) is shared for both anon and
> file. This is to maintain a common frame of reference.
> 
> In order for eviction to advance the min_seq of a type, all the per-zone
> lists in the oldest generation of that type must be empty.
> 
> The eviction logic only considers pages from eligible zones for
> eviction or promotion.
> 
>      scan_folios() {
> 	...
> 	for (zone = sc->reclaim_idx; zone >= 0; zone--)  {
> 	    ...
> 	    sort_folio(); 	// Promote
> 	    ...
> 	    isolate_folio(); 	// Evict
> 	}
> 	...
>      }
> 
> Consider the system has the movable zone configured and default 4
> generations. The current state of the system is as shown below
> (only illustrating one type for simplicity):
> 
> Type: ANON
> 
> 	Zone    DMA32     Normal    Movable    Device
> 
> 	Gen 0       0          0        4GB         0
> 
> 	Gen 1       0        1GB        1MB         0
> 
> 	Gen 2     1MB        4GB        1MB         0
> 
> 	Gen 3     1MB        1MB        1MB         0
> 
> Now consider there is a GFP_KERNEL allocation request (eligible zone
> index <= Normal), evict_folios() will return without doing any work
> since there are no pages to scan in the eligible zones of the oldest
> generation. Reclaim won't make progress until triggered from a ZONE_MOVABLE
> allocation request; which may not happen soon if there is a lot of free
> memory in the movable zone. This can lead to OOM kills, although there
> is 1GB pages in the Normal zone of Gen 1 that we have not yet tried to
> reclaim.
> 
> This issue is not seen in the conventional active/inactive LRU since
> there are no per-zone lists.
> 
> If there are no (not enough) folios to scan in the eligible zones, move
> folios from ineligible zone (zone_index > reclaim_index) to the next
> generation. This allows for the progression of min_seq and reclaiming
> from the next generation (Gen 1).
> 
> Qualcomm, Mediatek and raspberrypi [1] discovered this issue independently.
> 
> [1] https://github.com/raspberrypi/linux/issues/5395
> 
> Fixes: ac35a4902374 ("mm: multi-gen LRU: minimal implementation")
> Cc: stable@vger.kernel.org
> Cc: Yu Zhao <yuzhao@google.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Reported-by: Charan Teja Kalla <quic_charante@quicinc.com>
> Reported-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
> Signed-off-by: Kalesh Singh <kaleshsingh@google.com>

Whole series tested on MT8173 Elm Chromebook and MT6795 Xperia M5 as those are
low ram devices. Can't reproduce the issue described in your [1] link from RPi.

MediaTek:
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>

> ---
> 
> Changes in v2:
>    - Add Fixes tag and cc stable
> 
>   mm/vmscan.c | 18 ++++++++++++++----
>   1 file changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 4039620d30fe..489a4fc7d9b1 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -4889,7 +4889,8 @@ static int lru_gen_memcg_seg(struct lruvec *lruvec)
>    *                          the eviction
>    ******************************************************************************/
>   
> -static bool sort_folio(struct lruvec *lruvec, struct folio *folio, int tier_idx)
> +static bool sort_folio(struct lruvec *lruvec, struct folio *folio, struct scan_control *sc,
> +		       int tier_idx)
>   {
>   	bool success;
>   	int gen = folio_lru_gen(folio);
> @@ -4939,6 +4940,13 @@ static bool sort_folio(struct lruvec *lruvec, struct folio *folio, int tier_idx)
>   		return true;
>   	}
>   
> +	/* ineligible */
> +	if (zone > sc->reclaim_idx) {
> +		gen = folio_inc_gen(lruvec, folio, false);
> +		list_move_tail(&folio->lru, &lrugen->folios[gen][type][zone]);
> +		return true;
> +	}
> +
>   	/* waiting for writeback */
>   	if (folio_test_locked(folio) || folio_test_writeback(folio) ||
>   	    (type == LRU_GEN_FILE && folio_test_dirty(folio))) {
> @@ -4987,7 +4995,8 @@ static bool isolate_folio(struct lruvec *lruvec, struct folio *folio, struct sca
>   static int scan_folios(struct lruvec *lruvec, struct scan_control *sc,
>   		       int type, int tier, struct list_head *list)
>   {
> -	int gen, zone;
> +	int i;
> +	int gen;
>   	enum vm_event_item item;
>   	int sorted = 0;
>   	int scanned = 0;
> @@ -5003,9 +5012,10 @@ static int scan_folios(struct lruvec *lruvec, struct scan_control *sc,
>   
>   	gen = lru_gen_from_seq(lrugen->min_seq[type]);
>   
> -	for (zone = sc->reclaim_idx; zone >= 0; zone--) {
> +	for (i = MAX_NR_ZONES; i > 0; i--) {
>   		LIST_HEAD(moved);
>   		int skipped = 0;
> +		int zone = (sc->reclaim_idx + i) % MAX_NR_ZONES;
>   		struct list_head *head = &lrugen->folios[gen][type][zone];
>   
>   		while (!list_empty(head)) {
> @@ -5019,7 +5029,7 @@ static int scan_folios(struct lruvec *lruvec, struct scan_control *sc,
>   
>   			scanned += delta;
>   
> -			if (sort_folio(lruvec, folio, tier))
> +			if (sort_folio(lruvec, folio, sc, tier))
>   				sorted += delta;
>   			else if (isolate_folio(lruvec, folio, sc)) {
>   				list_add(&folio->lru, list);

Re: [PATCH v2 1/3] mm-unstable: Multi-gen LRU: Fix per-zone reclaim

[Charan Teja Kalla]

Thanks Kalesh for taking this to upstream.

On 8/2/2023 8:26 AM, Kalesh Singh wrote:
> MGLRU has a LRU list for each zone for each type (anon/file) in each
> generation:
> 
> 	long nr_pages[MAX_NR_GENS][ANON_AND_FILE][MAX_NR_ZONES];
> The min_seq (oldest generation) can progress independently for each
> type but the max_seq (youngest generation) is shared for both anon and
> file. This is to maintain a common frame of reference.
> 
> In order for eviction to advance the min_seq of a type, all the per-zone
> lists in the oldest generation of that type must be empty.
> 
> The eviction logic only considers pages from eligible zones for
> eviction or promotion.
> 
>     scan_folios() {
> 	...
> 	for (zone = sc->reclaim_idx; zone >= 0; zone--)  {
> 	    ...
> 	    sort_folio(); 	// Promote
> 	    ...
> 	    isolate_folio(); 	// Evict
> 	}
> 	...
>     }
> 
> Consider the system has the movable zone configured and default 4
> generations. The current state of the system is as shown below
> (only illustrating one type for simplicity):
> 
> Type: ANON
> 
> 	Zone    DMA32     Normal    Movable    Device
> 
> 	Gen 0       0          0        4GB         0
> 
> 	Gen 1       0        1GB        1MB         0
> 
> 	Gen 2     1MB        4GB        1MB         0
> 
> 	Gen 3     1MB        1MB        1MB         0
> 
> Now consider there is a GFP_KERNEL allocation request (eligible zone
> index <= Normal), evict_folios() will return without doing any work
> since there are no pages to scan in the eligible zones of the oldest
> generation. Reclaim won't make progress until triggered from a ZONE_MOVABLE
> allocation request; which may not happen soon if there is a lot of free
> memory in the movable zone. This can lead to OOM kills, although there
> is 1GB pages in the Normal zone of Gen 1 that we have not yet tried to
> reclaim.
> 
> This issue is not seen in the conventional active/inactive LRU since
> there are no per-zone lists.
> 
> If there are no (not enough) folios to scan in the eligible zones, move
> folios from ineligible zone (zone_index > reclaim_index) to the next
> generation. This allows for the progression of min_seq and reclaiming
> from the next generation (Gen 1).
> 
As discussing offline, I think this can make system to spend too much
time in scan_folios() in moving the pages from Gen-0 to Gen-1 of the
other zone which can result into OOM is not active when necessary.

> Qualcomm, Mediatek and raspberrypi [1] discovered this issue independently.
> 
> [1] https://github.com/raspberrypi/linux/issues/5395
> 
> Fixes: ac35a4902374 ("mm: multi-gen LRU: minimal implementation")
> Cc: stable@vger.kernel.org
> Cc: Yu Zhao <yuzhao@google.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Reported-by: Charan Teja Kalla <quic_charante@quicinc.com>
> Reported-by: Lecopzer Chen <lecopzer.chen@mediatek.com>
> Signed-off-by: Kalesh Singh <kaleshsingh@google.com>

We tested this patch on our systems for couple of weeks and aggressive
OOM is not observed which otherwise is easily reproducible.

Tested-by: Charan Teja Kalla <quic_charante@quicinc.com>