linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: "Christoph Lameter (Ampere)" <cl@gentwo.org>
Cc: linux-mm@kvack.org
Subject: Re: folio_alloc_buffers() doing allocations > order 1 with GFP_NOFAIL
Date: Wed, 1 Nov 2023 08:08:51 +0000	[thread overview]
Message-ID: <ZUIHk+PzpOLIKJZN@casper.infradead.org> (raw)
In-Reply-To: <6b42243e-f197-600a-5d22-56bd728a5ad8@gentwo.org>

On Tue, Oct 31, 2023 at 05:13:57PM -0700, Christoph Lameter (Ampere) wrote:
> Hi Matthew,
> 
> There is a strange warning on bootup related to folios. Seen it a couple of
> times before. Why does this occur?

Filesystems generally can't cope with failing to allocate a bufferhead.
So the buffer head code sets __GFP_NOFAIL.  That's better than trying
to implement __GFP_NOFAIL semantics in the fs code, right?

> [   20.878110] Call trace:
> [   20.878111]  get_page_from_freelist+0x214/0x17f8
> [   20.878116]  __alloc_pages+0x17c/0xe08
> [   20.878120]  __kmalloc_large_node+0xa0/0x170
> [   20.878123]  __kmalloc_node+0x120/0x1d0
> [   20.878125]  memcg_alloc_slab_cgroups+0x48/0xc0

Oho.  It's not buffer's fault, specifically.  memcg is allocating
its own metadata for the slab.  I decree this Not My Fault.

> [   20.878128]  memcg_slab_post_alloc_hook+0xa8/0x1c8
> [   20.878132]  kmem_cache_alloc+0x18c/0x338
> [   20.878135]  alloc_buffer_head+0x28/0xa0
> [   20.878138]  folio_alloc_buffers+0xe8/0x1c0
> [   20.878141]  folio_create_empty_buffers+0x2c/0x1e8
> [   20.878143]  folio_create_buffers+0x58/0x80
> [   20.878145]  block_read_full_folio+0x80/0x450
> [   20.878148]  blkdev_read_folio+0x24/0x38
> [   20.956921]  filemap_read_folio+0x60/0x138
> [   20.956925]  do_read_cache_folio+0x180/0x298
> [   20.965270]  read_cache_page+0x24/0x90
> [   20.965273]  __arm64_sys_swapon+0x2e0/0x1208
> [   20.965277]  invoke_syscall+0x78/0x108
> [   20.965282]  el0_svc_common.constprop.0+0x48/0xf0
> [   20.981702]  do_el0_svc+0x24/0x38
> [   20.993773]  el0t_64_sync_handler+0x100/0x130
> [   20.993776]  el0t_64_sync+0x190/0x198
> [   20.993779] ---[ end trace 0000000000000000 ]---
> [   20.999972] Adding 999420k swap on /dev/mapper/eng07sys--r113--vg-swap_1.
> Priority:-2 extents:1 across:999420k SS
> 
> This is due to
> 
> 
> 
> folio_alloc_buffers() setting GFP_NOFAIL:
> 
> 
> struct buffer_head *folio_alloc_buffers(struct folio *folio, unsigned long
> size,
>                                         bool retry)
> {
>         struct buffer_head *bh, *head;
>         gfp_t gfp = GFP_NOFS | __GFP_ACCOUNT;
>         long offset;
>         struct mem_cgroup *memcg, *old_memcg;
> 
>         if (retry)
>                 gfp |= __GFP_NOFAIL;

This isn't new.  It was introduced by 640ab98fb362 in 2017.
It seems reasonable to be able to kmalloc(512, GFP_NOFAIL).  It's the
memcg code which is having problems here.


  reply	other threads:[~2023-11-01  8:08 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-01  0:13 folio_alloc_buffers() doing allocations > order 1 with GFP_NOFAIL Christoph Lameter (Ampere)
2023-11-01  8:08 ` Matthew Wilcox [this message]
2023-11-07  2:57   ` cgroups: warning for metadata allocation with GFP_NOFAIL (was Re: folio_alloc_buffers() doing allocations > order 1 with GFP_NOFAIL) Christoph Lameter
2023-11-07 18:05     ` Roman Gushchin
2023-11-07 18:18       ` Shakeel Butt
2023-11-08 10:33       ` Michal Hocko
2023-11-09  6:37         ` Shakeel Butt
2023-11-09 17:36           ` Roman Gushchin
2023-11-07 19:24     ` Matthew Wilcox
2023-11-07 21:33       ` Roman Gushchin
2023-11-07 21:37         ` Matthew Wilcox
2023-11-10 13:38       ` Matthew Wilcox
2023-11-13 19:48         ` Christoph Lameter
2023-11-13 22:48           ` Matthew Wilcox
2023-11-14 17:29             ` Roman Gushchin

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=ZUIHk+PzpOLIKJZN@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=cl@gentwo.org \
    --cc=linux-mm@kvack.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 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).