Since mm-hotfixes-stable commit e509ad4d77e6 ("ext4: use bdev_getblk() to
avoid memory reclaim in readahead path") rightly replaced GFP_NOFAIL
allocations by GFP_NOWAIT allocations, I've occasionally been seeing
"page allocation failure: order:0" warnings under load: all with
ext4_sb_breadahead_unmovable() in the stack. I don't think those
warnings are of any interest: suppress them with __GFP_NOWARN.
Fixes: e509ad4d77e6 ("ext4: use bdev_getblk() to avoid memory reclaim in readahead path")
Signed-off-by: Hugh Dickins <[email protected]>
---
fs/ext4/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index c00ec159dea5..56a08fc5c5d5 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -262,7 +262,7 @@ struct buffer_head *ext4_sb_bread_unmovable(struct super_block *sb,
void ext4_sb_breadahead_unmovable(struct super_block *sb, sector_t block)
{
struct buffer_head *bh = bdev_getblk(sb->s_bdev, block,
- sb->s_blocksize, GFP_NOWAIT);
+ sb->s_blocksize, GFP_NOWAIT | __GFP_NOWARN);
if (likely(bh)) {
if (trylock_buffer(bh))
--
2.35.3
On Mon 23-10-23 23:26:08, Hugh Dickins wrote:
> Since mm-hotfixes-stable commit e509ad4d77e6 ("ext4: use bdev_getblk() to
> avoid memory reclaim in readahead path") rightly replaced GFP_NOFAIL
> allocations by GFP_NOWAIT allocations, I've occasionally been seeing
> "page allocation failure: order:0" warnings under load: all with
> ext4_sb_breadahead_unmovable() in the stack. I don't think those
> warnings are of any interest: suppress them with __GFP_NOWARN.
>
> Fixes: e509ad4d77e6 ("ext4: use bdev_getblk() to avoid memory reclaim in readahead path")
> Signed-off-by: Hugh Dickins <[email protected]>
Yeah, makes sense. Just the commit you mention isn't upstream yet so I'm
not sure whether the commit hash is stable. I guess something for Andrew to
figure out. In any case feel free to add:
Reviewed-by: Jan Kara <[email protected]>
Honza
> ---
> fs/ext4/super.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index c00ec159dea5..56a08fc5c5d5 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -262,7 +262,7 @@ struct buffer_head *ext4_sb_bread_unmovable(struct super_block *sb,
> void ext4_sb_breadahead_unmovable(struct super_block *sb, sector_t block)
> {
> struct buffer_head *bh = bdev_getblk(sb->s_bdev, block,
> - sb->s_blocksize, GFP_NOWAIT);
> + sb->s_blocksize, GFP_NOWAIT | __GFP_NOWARN);
>
> if (likely(bh)) {
> if (trylock_buffer(bh))
> --
> 2.35.3
>
--
Jan Kara <[email protected]>
SUSE Labs, CR
On Tue, 24 Oct 2023 12:03:18 +0200 Jan Kara <[email protected]> wrote:
> On Mon 23-10-23 23:26:08, Hugh Dickins wrote:
> > Since mm-hotfixes-stable commit e509ad4d77e6 ("ext4: use bdev_getblk() to
> > avoid memory reclaim in readahead path") rightly replaced GFP_NOFAIL
> > allocations by GFP_NOWAIT allocations, I've occasionally been seeing
> > "page allocation failure: order:0" warnings under load: all with
> > ext4_sb_breadahead_unmovable() in the stack. I don't think those
> > warnings are of any interest: suppress them with __GFP_NOWARN.
> >
> > Fixes: e509ad4d77e6 ("ext4: use bdev_getblk() to avoid memory reclaim in readahead path")
> > Signed-off-by: Hugh Dickins <[email protected]>
>
> Yeah, makes sense. Just the commit you mention isn't upstream yet so I'm
> not sure whether the commit hash is stable.
e509ad4d77e6 is actually in mm-stable so yes, the hash should be stable.
On Tue, Oct 24, 2023 at 07:53:43AM -0700, Andrew Morton wrote:
> On Tue, 24 Oct 2023 12:03:18 +0200 Jan Kara <[email protected]> wrote:
>
> > On Mon 23-10-23 23:26:08, Hugh Dickins wrote:
> > > Since mm-hotfixes-stable commit e509ad4d77e6 ("ext4: use bdev_getblk() to
> > > avoid memory reclaim in readahead path") rightly replaced GFP_NOFAIL
> > > allocations by GFP_NOWAIT allocations, I've occasionally been seeing
> > > "page allocation failure: order:0" warnings under load: all with
> > > ext4_sb_breadahead_unmovable() in the stack. I don't think those
> > > warnings are of any interest: suppress them with __GFP_NOWARN.
> > >
> > > Fixes: e509ad4d77e6 ("ext4: use bdev_getblk() to avoid memory reclaim in readahead path")
> > > Signed-off-by: Hugh Dickins <[email protected]>
> >
> > Yeah, makes sense. Just the commit you mention isn't upstream yet so I'm
> > not sure whether the commit hash is stable.
>
> e509ad4d77e6 is actually in mm-stable so yes, the hash should be stable.
GFP_NOWAIT is a loaded gun pointing at our own feet. It's almost
expected to fail (and that's documented in a few places, eg
Documentation/core-api/memory-allocation.rst)
Why do we do this to ourselves? There's precedent for having
__GFP_NOWARN included in the flags, eg GFP_TRANSHUGE_LIGHT has it.
There are ~400 occurrences of GFP_NOWAIT in the kernel (many in
comments, it must be said!) and ~350 of them do not have GFP_NOWARN
attached to them. At least not on the same line. To choose a random
example, fs/iomap/buffered-io.c:
if (flags & IOMAP_NOWAIT)
gfp = GFP_NOWAIT;
else
gfp = GFP_NOFS | __GFP_NOFAIL;
That should clearly have had a NOWARN attached to it, but it's not
a code path that's commonly used, so we won't fix it for a few years.
Similarly, in Ceph:
if (IS_ENCRYPTED(inode)) {
pages[locked_pages] =
fscrypt_encrypt_pagecache_blocks(page,
PAGE_SIZE, 0,
locked_pages ? GFP_NOWAIT : GFP_NOFS);
... actually, this one looks fine because it goes to mempool_alloc()
which adds __GFP_NOWARN itself!
There are a bunch of places which use it as an argument to idr_alloc(),
generally after having called idr_prealloc() and then taken a spinlock.
Those don't care whether NOWARN is set or not because they won't
allocate.
Anyway, are there good arguments against this?
diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
index 6583a58670c5..ae994534a12a 100644
--- a/include/linux/gfp_types.h
+++ b/include/linux/gfp_types.h
@@ -274,7 +274,8 @@ typedef unsigned int __bitwise gfp_t;
* accounted to kmemcg.
*
* %GFP_NOWAIT is for kernel allocations that should not stall for direct
- * reclaim, start physical IO or use any filesystem callback.
+ * reclaim, start physical IO or use any filesystem callback. It is very
+ * likely to fail to allocate memory, even for very small allocations.
*
* %GFP_NOIO will use direct reclaim to discard clean pages or slab pages
* that do not require the starting of any physical IO.
@@ -325,7 +326,7 @@ typedef unsigned int __bitwise gfp_t;
#define GFP_ATOMIC (__GFP_HIGH|__GFP_KSWAPD_RECLAIM)
#define GFP_KERNEL (__GFP_RECLAIM | __GFP_IO | __GFP_FS)
#define GFP_KERNEL_ACCOUNT (GFP_KERNEL | __GFP_ACCOUNT)
-#define GFP_NOWAIT (__GFP_KSWAPD_RECLAIM)
+#define GFP_NOWAIT (__GFP_KSWAPD_RECLAIM | __GFP_NOWARN)
#define GFP_NOIO (__GFP_RECLAIM)
#define GFP_NOFS (__GFP_RECLAIM | __GFP_IO)
#define GFP_USER (__GFP_RECLAIM | __GFP_IO | __GFP_FS | __GFP_HARDWALL)