From: "Theodore Ts'o" <tytso@mit.edu>
To: Michal Hocko <mhocko@suse.com>
Cc: Kent Overstreet <kent.overstreet@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Hellwig <hch@lst.de>,
Yafang Shao <laoar.shao@gmail.com>,
jack@suse.cz, Vlastimil Babka <vbabka@suse.cz>,
Dave Chinner <dchinner@redhat.com>,
Christian Brauner <brauner@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-bcachefs@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/2 v2] remove PF_MEMALLOC_NORECLAIM
Date: Thu, 5 Sep 2024 09:53:26 -0400 [thread overview]
Message-ID: <20240905135326.GU9627@mit.edu> (raw)
In-Reply-To: <ZtmVej0fbVxrGPVz@tiehlicka>
On Thu, Sep 05, 2024 at 01:26:50PM +0200, Michal Hocko wrote:
> > > > > This is exactly GFP_KERNEL semantic for low order allocations or
> > > > > kvmalloc for that matter. They simply never fail unless couple of corner
> > > > > cases - e.g. the allocating task is an oom victim and all of the oom
> > > > > memory reserves have been consumed. This is where we call "not possible
> > > > > to allocate".
> > > >
> > > > Which does beg the question of why GFP_NOFAIL exists.
> > >
> > > Exactly for the reason that even rare failure is not acceptable and
> > > there is no way to handle it other than keep retrying. Typical code was
> > > while (!(ptr = kmalloc()))
> > > ;
> >
> > But is it _rare_ failure, or _no_ failure?
> >
> > You seem to be saying (and I just reviewed the code, it looks like
> > you're right) that there is essentially no difference in behaviour
> > between GFP_KERNEL and GFP_NOFAIL.
That may be the currrent state of affiars; but is it
****guaranteed**** forever and ever, amen, that GFP_KERNEL will never
fail if the amount of memory allocated was lower than a particular
multiple of the page size? If so, what is that size? I've checked,
and this is not documented in the formal interface.
> The fundamental difference is that (appart from unsupported allocation
> mode/size) the latter never returns NULL and you can rely on that fact.
> Our docummentation says:
> * %__GFP_NOFAIL: The VM implementation _must_ retry infinitely: the caller
> * cannot handle allocation failures. The allocation could block
> * indefinitely but will never return with failure. Testing for
> * failure is pointless.
So if the documentation is going to give similar guarantees, as
opposed to it being an accident of the current implementation that is
subject to change at any time, then sure, we can probably get away
with all or most of ext4's uses of __GFP_NOFAIL. But I don't want to
do that and then have a "Lucy and Charlie Brown" moment from the
Peanuts comics strip where the football suddenly gets snatched away
from us[1] (and many file sytem users will be very, very sad and/or
angry).
[1] https://www.cracked.com/article_37831_good-grief-how-lucy-pulling-the-football-away-from-charlie-brown-became-a-signature-peanuts-gag.html
It might be that other file systems have requirements which isblarger
than the not-formally-defined GFP_KMALLOC guarantee, but it's true we
can probably reduce the usage of GFP_NOFAIL if this guarantee is
formalized.
- Ted
next prev parent reply other threads:[~2024-09-05 13:54 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-02 9:51 [PATCH 0/2 v2] remove PF_MEMALLOC_NORECLAIM Michal Hocko
2024-09-02 9:51 ` [PATCH 1/2] bcachefs: do not use PF_MEMALLOC_NORECLAIM Michal Hocko
2024-09-05 9:28 ` kernel test robot
2024-09-02 9:51 ` [PATCH 2/2] Revert "mm: introduce PF_MEMALLOC_NORECLAIM, PF_MEMALLOC_NOWARN" Michal Hocko
2024-09-02 9:53 ` [PATCH 0/2 v2] remove PF_MEMALLOC_NORECLAIM Kent Overstreet
2024-09-02 21:52 ` Andrew Morton
2024-09-02 22:32 ` Kent Overstreet
2024-09-03 7:06 ` Michal Hocko
2024-09-04 16:15 ` Kent Overstreet
2024-09-04 16:50 ` Michal Hocko
2024-09-03 23:53 ` Kent Overstreet
2024-09-04 7:14 ` Michal Hocko
2024-09-04 16:05 ` Kent Overstreet
2024-09-04 16:46 ` Michal Hocko
2024-09-04 18:03 ` Kent Overstreet
2024-09-04 22:34 ` Dave Chinner
2024-09-04 23:05 ` Kent Overstreet
2024-09-05 11:26 ` Michal Hocko
2024-09-05 13:53 ` Theodore Ts'o [this message]
2024-09-05 14:05 ` Kent Overstreet
2024-09-05 15:24 ` Theodore Ts'o
2024-09-05 14:12 ` Michal Hocko
2024-09-03 5:13 ` Christoph Hellwig
2024-09-04 16:27 ` Kent Overstreet
2024-09-04 17:01 ` Michal Hocko
2024-09-10 19:29 ` Andrew Morton
2024-09-10 19:37 ` Kent Overstreet
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=20240905135326.GU9627@mit.edu \
--to=tytso@mit.edu \
--cc=akpm@linux-foundation.org \
--cc=brauner@kernel.org \
--cc=dchinner@redhat.com \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=jmorris@namei.org \
--cc=kent.overstreet@linux.dev \
--cc=laoar.shao@gmail.com \
--cc=linux-bcachefs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mhocko@suse.com \
--cc=paul@paul-moore.com \
--cc=serge@hallyn.com \
--cc=vbabka@suse.cz \
--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).