From: Mel Gorman <mgorman@techsingularity.net>
To: Alexey Avramov <hakavlad@inbox.lv>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
mhocko@suse.com, vbabka@suse.cz, neilb@suse.de,
akpm@linux-foundation.org, corbet@lwn.net, riel@surriel.com,
hannes@cmpxchg.org, david@fromorbit.com, willy@infradead.org,
hdanton@sina.com, penguin-kernel@i-love.sakura.ne.jp,
oleksandr@natalenko.name, kernel@xanmod.org,
michael@michaellarabel.com, aros@gmx.com, hakavlad@gmail.com
Subject: Re: mm: 5.16 regression: reclaim_throttle leads to stall in near-OOM conditions
Date: Wed, 24 Nov 2021 11:50:07 +0000 [thread overview]
Message-ID: <20211124115007.GG3366@techsingularity.net> (raw)
In-Reply-To: <20211124195449.33f31e7f@mail.inbox.lv>
On Wed, Nov 24, 2021 at 07:54:49PM +0900, Alexey Avramov wrote:
> > it does eventually get killed OOM
>
> However, a full minute freeze can be a great evil in many situations -
> during such a freeze, the system is completely unresponsive.
>
> So my next question is: How reasonable is the value MAX_RECLAIM_RETRIES?
> Is it also get "out of thin air"?
>
The value is out of thin air but adjusting it may reintroduce issues
with kswapd running at 100% CPU.
> And would it make sense to have buttons to adjust the timeouts?
I don't think we should introduce a tunable for something like this,
it'll be impossible to use properly but can you test this?
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 07db03883062..aa72c0f39dcc 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1058,6 +1058,14 @@ void reclaim_throttle(pg_data_t *pgdat, enum vmscan_throttle_state reason)
break;
case VMSCAN_THROTTLE_NOPROGRESS:
timeout = HZ/2;
+
+ /*
+ * If kswapd is disabled, use the minimum timeout as the
+ * system may be at or near OOM.
+ */
+ if (pgdat->kswapd_failures >= MAX_RECLAIM_RETRIES)
+ timeout = 1;
+
break;
case VMSCAN_THROTTLE_ISOLATED:
timeout = HZ/50;
@@ -3395,7 +3403,7 @@ static void consider_reclaim_throttle(pg_data_t *pgdat, struct scan_control *sc)
return;
/* Throttle if making no progress at high prioities. */
- if (sc->priority < DEF_PRIORITY - 2)
+ if (sc->priority < DEF_PRIORITY - 2 && !sc->nr_reclaimed)
reclaim_throttle(pgdat, VMSCAN_THROTTLE_NOPROGRESS);
}
@@ -3415,6 +3423,7 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc)
unsigned long nr_soft_scanned;
gfp_t orig_mask;
pg_data_t *last_pgdat = NULL;
+ pg_data_t *first_pgdat = NULL;
/*
* If the number of buffer_heads in the machine exceeds the maximum
@@ -3478,14 +3487,18 @@ static void shrink_zones(struct zonelist *zonelist, struct scan_control *sc)
/* need some check for avoid more shrink_zone() */
}
+ if (!first_pgdat)
+ first_pgdat = zone->zone_pgdat;
+
/* See comment about same check for global reclaim above */
if (zone->zone_pgdat == last_pgdat)
continue;
last_pgdat = zone->zone_pgdat;
shrink_node(zone->zone_pgdat, sc);
- consider_reclaim_throttle(zone->zone_pgdat, sc);
}
+ consider_reclaim_throttle(first_pgdat, sc);
+
/*
* Restore to original mask to avoid the impact on the caller if we
* promoted it to __GFP_HIGHMEM.
next prev parent reply other threads:[~2021-11-24 11:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-23 16:19 mm: 5.16 regression: reclaim_throttle leads to stall in near-OOM conditions Alexey Avramov
2021-11-24 7:40 ` Thorsten Leemhuis
2021-11-28 8:06 ` mm: 5.16 regression: reclaim_throttle leads to stall in near-OOM conditions #justforregzbot Thorsten Leemhuis
2021-11-24 10:35 ` mm: 5.16 regression: reclaim_throttle leads to stall in near-OOM conditions Mel Gorman
2021-11-24 10:54 ` Alexey Avramov
2021-11-24 11:50 ` Mel Gorman [this message]
2021-11-24 12:03 ` Alexey Avramov
2021-11-24 12:44 ` Alexey Avramov
2021-11-24 14:33 ` Mel Gorman
2021-11-26 16:06 ` Alexey Avramov
2021-11-26 16:24 ` Mel Gorman
2021-12-20 8:50 ` Sultan Alsawaf
2021-11-27 19:37 ` Alexey Avramov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211124115007.GG3366@techsingularity.net \
--to=mgorman@techsingularity.net \
--cc=akpm@linux-foundation.org \
--cc=aros@gmx.com \
--cc=corbet@lwn.net \
--cc=david@fromorbit.com \
--cc=hakavlad@gmail.com \
--cc=hakavlad@inbox.lv \
--cc=hannes@cmpxchg.org \
--cc=hdanton@sina.com \
--cc=kernel@xanmod.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=michael@michaellarabel.com \
--cc=neilb@suse.de \
--cc=oleksandr@natalenko.name \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=riel@surriel.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.