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 10:35:50 +0000 [thread overview]
Message-ID: <20211124103550.GE3366@techsingularity.net> (raw)
In-Reply-To: <20211124011954.7cab9bb4@mail.inbox.lv>
On Wed, Nov 24, 2021 at 01:19:54AM +0900, Alexey Avramov wrote:
> I found stalls in near-OOM conditions with Linux 5.16. This is not the
> hang-up that was reported by Artem S. Tashkinov in 2019 [1]. It's a *new*
> regression. I will demonstrate this with one simple experiment, which I
> will reproduce with different kernels or settings.
>
> With older versions of the kernel, running the `tail /dev/zero` command
> usually quickly leads to OOM condition.
>
> I will run the command `for i in {1...3}; do tail /dev/zero; done` and log
> PSI metrics (using psi2log script from nohang v0.2.0 [2]) and some values
> from `/proc/meminfo` (using mem2log v0.1.0 [3]) while this command is
> running. During the experiment a single tab browser will be kept opened in
> which some video will be playing.
>
Ok, I can reproduce this. However, it does eventually get killed OOM so
the system makes progress but maybe the throttling should be for very
short intervals if failing to make progress and there have been multiple
reclaim failures recently. Disabling the throttling entirely just results
in cases where 100% CPU is used spinning through lru lists.
Thanks for the report
--
Mel Gorman
SUSE Labs
next prev parent reply other threads:[~2021-11-24 10:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20211124011954.7cab9bb4@mail.inbox.lv>
2021-11-24 7:40 ` Thorsten Leemhuis
2021-11-24 10:35 ` Mel Gorman [this message]
[not found] ` <20211124195449.33f31e7f@mail.inbox.lv>
2021-11-24 11:50 ` Mel Gorman
[not found] ` <20211124214443.5c179d34@mail.inbox.lv>
2021-11-24 14:33 ` Mel Gorman
[not found] ` <20211127010631.4e33a432@mail.inbox.lv>
2021-11-26 16:24 ` Mel Gorman
2021-12-20 8:50 ` Sultan Alsawaf
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=20211124103550.GE3366@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox