From: tytso@mit.edu
To: Andrew Morton <akpm@linux-foundation.org>
Cc: David Rientjes <rientjes@google.com>,
Dave Jones <davej@redhat.com>, Fabian Frederick <fabf@skynet.be>,
linux-kernel <linux-kernel@vger.kernel.org>,
reiserfs-devel@vger.kernel.org, Joe Perches <joe@perches.com>
Subject: Re: [RFC 1/1] fs/reiserfs/journal.c: Remove obsolete __GFP_NOFAIL
Date: Wed, 26 Mar 2014 09:29:36 -0400 [thread overview]
Message-ID: <20140326132936.GB4907@thunk.org> (raw)
In-Reply-To: <20140325233209.31756c92.akpm@linux-foundation.org>
On Tue, Mar 25, 2014 at 11:32:09PM -0700, Andrew Morton wrote:
> Well, there are always alternatives. For example ext3 could
> preallocate a single transaction_t and a single IO page and fall back
> to synchronous page-at-a-time journal writes. But I can totally see
> that such things are unattractive: heaps of new code which is never
> tested in real life. The page allocator works so damn well that it
> doesn't make sense to implement it.
I'm not sure that there are _always_ solutions. For example, ext3
still needs to use buffer cache to do the I/O, and that may require
allocations as well. Fortunately, this was patched around other ways
to avoid livelock issues in the page cleaner in 2013: 84235de394d977
But that's another new user of GFP_NOFAIL (and one added three years
after David tried to declare There Shalt Be No New Users of
GFP_NOFAIL), and sure, we could probably patch around that by having
places where there's no other alternaive to keep a preallocated batch
of pages and/or allocated structures at each code site. But that's as
bad as looping at each code site; in fact, wouldn't it be better if
the allocator wants to avoid looping, to have a separate batch of
pages which (ala GFP_ATOMIC) which is reserved for just for GFP_NOFAIL
allocations when all else fails?
(BTW, we have a similar issue with bio's in the block layer, but
fortunately, those structures are relatively small, and since they are
in their own slab cache, and are constantly being used and then
recycled, it's in practice rare that allocations will fail when we are
in a desparate low memory situation. But technically there will be
places where we should pass a gfp_t down to the block layers, and use
GFP_NOFAIL if we really want to make sure that memory allocations
needed to try to clean pages and/or avoid user data corruption are
needed.)
> Please use NOFAIL ;) The core page allocator will always be able to
> implement this better than callers.
I'll convert jbd2 to use NOFAIL. :-)
Cheers,
- Ted
next prev parent reply other threads:[~2014-03-26 13:29 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-21 16:18 [RFC 1/1] fs/reiserfs/journal.c: Remove obsolete __GFP_NOFAIL Fabian Frederick
2014-03-21 20:00 ` Andrew Morton
2014-03-21 23:21 ` Fabian Frederick
2014-03-21 23:27 ` Andrew Morton
2014-03-22 17:03 ` tytso
2014-03-22 17:15 ` Andrew Morton
2014-03-22 17:26 ` tytso
2014-03-22 17:32 ` tytso
2014-03-22 17:55 ` Andrew Morton
2014-03-22 18:12 ` tytso
2014-03-22 18:56 ` Joe Perches
2014-03-26 1:07 ` David Rientjes
2014-03-22 19:24 ` Dave Jones
2014-03-26 1:06 ` David Rientjes
2014-03-26 6:19 ` tytso
2014-03-26 6:32 ` Andrew Morton
2014-03-26 13:29 ` tytso [this message]
2014-03-27 4:38 ` David Rientjes
2014-03-22 21:13 ` Fabian Frederick
2014-03-24 14:00 ` One Thousand Gnomes
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=20140326132936.GB4907@thunk.org \
--to=tytso@mit.edu \
--cc=akpm@linux-foundation.org \
--cc=davej@redhat.com \
--cc=fabf@skynet.be \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=reiserfs-devel@vger.kernel.org \
--cc=rientjes@google.com \
/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