From: "Theodore Ts'o" <tytso@mit.edu>
To: NeilBrown <neilb@suse.de>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Andreas Dilger <adilger.kernel@dilger.ca>,
"Darrick J. Wong" <djwong@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
Mel Gorman <mgorman@suse.com>,
linux-xfs@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 3/6] EXT4: Remove ENOMEM/congestion_wait() loops.
Date: Tue, 14 Sep 2021 20:28:31 -0400 [thread overview]
Message-ID: <YUE+L19JyjqWh+Md@mit.edu> (raw)
In-Reply-To: <163157838437.13293.14244628630141187199.stgit@noble.brown>
On Tue, Sep 14, 2021 at 10:13:04AM +1000, NeilBrown wrote:
>
> Of particular interest is the ext4_journal_start family of calls which
> can now have EXT4_EX_NOFAIL 'or'ed in to the 'type'. This could be seen
> as a blurring of types. However 'type' is 8 bits, and EXT4_EX_NOFAIL is
> a high bit, so it is safe in practice.
I'm really not fond of this type blurring. What I'd suggeset doing
instead is adding a "gfp_t gfp_mask" parameter to the
__ext4_journal_start_sb(). With the exception of one call site in
fs/ext4/ialloc.c, most of the callers of __ext4_journal_start_sb() are
via #define helper macros or inline funcions. So it would just
require adding a GFP_NOFS as an extra parameter to the various macros
and inline functions which call __ext4_journal_start_sb() in
ext4_jbd2.h.
The function ext4_journal_start_with_revoke() is called exactly once
so we could just bury the __GFP_NOFAIL in the definition of that
macros, e.g.:
#define ext4_journal_start_with_revoke(inode, type, blocks, revoke_creds) \
__ext4_journal_start((inode), __LINE__, (type), (blocks), 0, \
GFP_NOFS | __GFP_NOFAIL, (revoke_creds))
but it's probably better to do something like this:
#define ext4_journal_start_with_revoke(gfp_mask, inode, type, blocks, revoke_creds) \
__ext4_journal_start((inode), __LINE__, (type), (blocks), 0, \
gfp_mask, (revoke_creds))
So it's explicit in the C function ext4_ext_remove_space() in
fs/ext4/extents.c that we are explicitly requesting the __GFP_NOFAIL
behavior.
Does that make sense?
- Ted
next prev parent reply other threads:[~2021-09-15 0:28 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-14 0:13 [PATCH 0/6] congestion_wait() and GFP_NOFAIL NeilBrown
2021-09-14 0:13 ` [PATCH 2/6] MM: annotate congestion_wait() and wait_iff_congested() as ineffective NeilBrown
2021-09-15 11:56 ` Michal Hocko
2021-09-16 22:13 ` NeilBrown
2021-09-14 0:13 ` [PATCH 5/6] XFS: remove congestion_wait() loop from kmem_alloc() NeilBrown
2021-09-14 1:31 ` Dave Chinner
2021-09-14 3:27 ` NeilBrown
2021-09-14 6:05 ` Dave Chinner
2021-09-14 0:13 ` [PATCH 3/6] EXT4: Remove ENOMEM/congestion_wait() loops NeilBrown
2021-09-14 16:34 ` Mel Gorman
2021-09-14 21:48 ` NeilBrown
2021-09-15 12:06 ` Michal Hocko
2021-09-15 22:35 ` NeilBrown
2021-09-16 0:37 ` Dave Chinner
2021-09-16 6:52 ` Michal Hocko
2021-09-14 23:55 ` Dave Chinner
2021-09-15 8:59 ` Mel Gorman
2021-09-15 12:20 ` Michal Hocko
2021-09-15 14:35 ` Mel Gorman
2021-09-15 22:38 ` Dave Chinner
2021-09-16 9:00 ` Mel Gorman
2021-09-15 0:28 ` Theodore Ts'o [this message]
2021-09-15 5:25 ` NeilBrown
2021-09-15 17:02 ` Theodore Ts'o
2021-09-14 0:13 ` [PATCH 1/6] MM: improve documentation for __GFP_NOFAIL NeilBrown
2021-09-15 11:51 ` Michal Hocko
2021-09-14 0:13 ` [PATCH 6/6] XFS: remove congestion_wait() loop from xfs_buf_alloc_pages() NeilBrown
2021-09-14 2:08 ` Dave Chinner
2021-09-14 2:35 ` NeilBrown
2021-09-14 5:33 ` Dave Chinner
2021-09-14 16:45 ` Mel Gorman
2021-09-14 21:13 ` NeilBrown
2021-09-14 0:13 ` [PATCH 4/6] EXT4: remove congestion_wait from ext4_bio_write_page, and simplify NeilBrown
2021-09-17 2:56 [PATCH 0/6 v2] congestion_wait() and GFP_NOFAIL NeilBrown
2021-09-17 2:56 ` [PATCH 3/6] EXT4: Remove ENOMEM/congestion_wait() loops NeilBrown
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=YUE+L19JyjqWh+Md@mit.edu \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=akpm@linux-foundation.org \
--cc=djwong@kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=mgorman@suse.com \
--cc=neilb@suse.de \
--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.