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
Cc: Yu Zhao <[email protected]>
Cc: Andrew Morton <[email protected]>
Reported-by: Charan Teja Kalla <[email protected]>
Reported-by: Lecopzer Chen <[email protected]>
Signed-off-by: Kalesh Singh <[email protected]>
---
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
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).
Cc: Yu Zhao <[email protected]>
Cc: Andrew Morton <[email protected]>
Signed-off-by: Kalesh Singh <[email protected]>
---
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
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/
Cc: Yu Zhao <[email protected]>
Cc: Aneesh Kumar K V <[email protected]>
Cc: Andrew Morton <[email protected]>
Signed-off-by: Kalesh Singh <[email protected]>
---
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
On Tue, Aug 1, 2023 at 6:19 PM Kalesh Singh <[email protected]> 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).
>
> Qualcomm, Mediatek and raspberrypi [1] discovered this issue independently.
>
> [1] https://github.com/raspberrypi/linux/issues/5395
>
> Cc: Yu Zhao <[email protected]>
> Cc: Andrew Morton <[email protected]>
> Reported-by: Charan Teja Kalla <[email protected]>
> Reported-by: Lecopzer Chen <[email protected]>
> Signed-off-by: Kalesh Singh <[email protected]>
LGTM. But I think we need the Fixes tag and Cc stable.
On Tue, Aug 1, 2023 at 7:08 PM Yu Zhao <[email protected]> wrote:
>
> On Tue, Aug 1, 2023 at 6:19 PM Kalesh Singh <[email protected]> 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).
> >
> > Qualcomm, Mediatek and raspberrypi [1] discovered this issue independently.
> >
> > [1] https://github.com/raspberrypi/linux/issues/5395
> >
> > Cc: Yu Zhao <[email protected]>
> > Cc: Andrew Morton <[email protected]>
> > Reported-by: Charan Teja Kalla <[email protected]>
> > Reported-by: Lecopzer Chen <[email protected]>
> > Signed-off-by: Kalesh Singh <[email protected]>
>
> LGTM. But I think we need the Fixes tag and Cc stable.
I've reposted the patches with fixes tag and stable cc'ed at:
https://lore.kernel.org/lkml/[email protected]/#t
Thanks,
Kalesh