From: Michal Hocko <mhocko@suse.com>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: Christoph Hellwig <hch@infradead.org>,
akpm@linux-foundation.org, viro@zeniv.linux.org.uk,
brauner@kernel.org, jack@suse.cz, david@fromorbit.com,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
Kent Overstreet <kent.overstreet@linux.dev>
Subject: Re: [PATCH 1/2] mm: Add memalloc_nowait_{save,restore}
Date: Thu, 15 Aug 2024 08:51:52 +0200 [thread overview]
Message-ID: <Zr2liCOFDqPiNk6_@tiehlicka> (raw)
In-Reply-To: <CALOAHbCnWDPnErCDOWaPo6vc__G56wzmX-j=bGrwAx6J26DgJg@mail.gmail.com>
On Thu 15-08-24 14:32:10, Yafang Shao wrote:
> On Thu, Aug 15, 2024 at 2:22 PM Michal Hocko <mhocko@suse.com> wrote:
[...]
> > Let me repeat, nested NOFAIL allocations will BUG_ON on failure.
>
> The key question is whether it actually fails after we've already
> woken up kswapd. Have we encountered real issues, or is this just
> based on code review?
Depleting memory to the level that even min memory reserves is
insufficient is not a theoretical concern. OOMing the system is a real
thing!
> Instead of allowing it to fail, why not allocate
> from the reserve memory to prevent this from happening?
Because those memory reserves are shared and potentially required by
other more important users which cannot make forward progress without
them. And even with that, those can get depleted so the failure point is
just a matter of a specific memory consumption pattern. The failure
could be more rare but that also means much harder to predict and test
for. Really there are no ways around non sleeping GFP_NOFAIL, either you
disalow them or you just create a busy loop inside the allocator. We
have chosen the first option because that is a saner model to support.
--
Michal Hocko
SUSE Labs
next prev parent reply other threads:[~2024-08-15 6:51 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-12 9:05 [PATCH 0/2] mm: Add readahead support for IOCB_NOWAIT Yafang Shao
2024-08-12 9:05 ` [PATCH 1/2] mm: Add memalloc_nowait_{save,restore} Yafang Shao
2024-08-12 11:37 ` Christoph Hellwig
2024-08-12 12:59 ` Yafang Shao
2024-08-12 13:21 ` Christoph Hellwig
2024-08-13 2:09 ` Yafang Shao
2024-08-14 5:27 ` Christoph Hellwig
2024-08-14 7:33 ` Yafang Shao
2024-09-01 20:24 ` Vlastimil Babka
2024-09-01 20:42 ` Kent Overstreet
2024-08-14 7:42 ` Michal Hocko
2024-08-14 8:12 ` Yafang Shao
2024-08-14 12:43 ` Michal Hocko
2024-08-15 3:26 ` Yafang Shao
2024-08-15 6:22 ` Michal Hocko
2024-08-15 6:32 ` Yafang Shao
2024-08-15 6:51 ` Michal Hocko [this message]
2024-08-16 8:17 ` [PATCH] mm: document risk of PF_MEMALLOC_NORECLAIM Michal Hocko
2024-08-16 8:22 ` Christoph Hellwig
2024-08-16 8:54 ` Michal Hocko
2024-08-16 14:26 ` Christoph Hellwig
2024-08-16 15:57 ` Michal Hocko
2024-08-21 7:30 ` Michal Hocko
2024-08-21 11:44 ` Christoph Hellwig
2024-08-21 12:37 ` Michal Hocko
2024-08-22 9:09 ` Christian Brauner
2024-08-17 2:29 ` Yafang Shao
2024-08-19 7:57 ` Michal Hocko
2024-08-12 16:48 ` [PATCH 1/2] mm: Add memalloc_nowait_{save,restore} Kent Overstreet
2024-08-14 5:24 ` Christoph Hellwig
2024-08-14 0:28 ` Dave Chinner
2024-08-14 2:19 ` Yafang Shao
2024-08-14 5:42 ` Dave Chinner
2024-08-14 7:32 ` Yafang Shao
2024-08-15 2:54 ` Dave Chinner
2024-08-15 3:38 ` Yafang Shao
2024-08-12 9:05 ` [PATCH 2/2] mm: allow read-ahead with IOCB_NOWAIT set Yafang Shao
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=Zr2liCOFDqPiNk6_@tiehlicka \
--to=mhocko@suse.com \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=jack@suse.cz \
--cc=kent.overstreet@linux.dev \
--cc=laoar.shao@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=viro@zeniv.linux.org.uk \
/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;
as well as URLs for NNTP newsgroup(s).