linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Christoph Lameter (Ampere)" <cl@gentwo.org>
To: Matthew Wilcox <willy@infradead.org>
Cc: linux-mm@kvack.org
Subject: folio_alloc_buffers() doing allocations > order 1 with GFP_NOFAIL
Date: Tue, 31 Oct 2023 17:13:57 -0700 (PDT)	[thread overview]
Message-ID: <6b42243e-f197-600a-5d22-56bd728a5ad8@gentwo.org> (raw)

Hi Matthew,

There is a strange warning on bootup related to folios. Seen it a couple 
of times before. Why does this occur?



        Activating swap
     20.765039] ------------[ cut here ]------------
[   20.772475] WARNING: CPU: 35 PID: 1152 at mm/page_alloc.c:2774 get_page_from_freelist+0x214/0x17f8
[   20.784194] Modules linked in:
[   20.784197] CPU: 35 PID: 1152 Comm: swapon Not tainted 6.6.0-base #109
[   20.784202] Hardware name: WIWYNN Mt.Jade Server System B81.03001.0014/Mt.Jade Motherboard, BIOS 2.10.20230517 (SCP: 2.10.20230517) 2023/05/17
[   20.808072] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   20.808075] pc : get_page_from_freelist+0x214/0x17f8
[   20.808080] lr : get_page_from_freelist+0xaa8/0x17f8
[   20.808084] sp : ffff800094623510
[   20.808085] x29: ffff800094623510 x28: 0000000000000000 x27: ffff083f7fffe700
[   20.808089] x26: 0000000000000000 x25: 0000000000000004 x24: ffff083f7fffe700
[   20.808093] x23: ffff083f7fffe700 x22: 0000000000012dd8 x21: ffff8000828cf000
[   20.808096] x20: 0000000000000002 x19: 0000000000000801 x18: 0000000000000000
[   20.808100] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[   20.808102] x14: 0000000000000000 x13: ffff07ff917f0c7b x12: 0000000000000005
[   20.808105] x11: 0000000000000000 x10: ffff083f7fffe8f0 x9 : 0000000000000000
[   20.808108] x8 : ffff083f7fffe8e0 x7 : ffff083f7fffe8d0 x6 : ffff083f7fffe700
[   20.878104] x5 : ffff083f7fffe910 x4 : fffffc1fff3e1708 x3 : ffff083f7fffe900
[   20.878107] x2 : ffff083f7fffe7d0 x1 : ffff800094623710 x0 : 0000000000008000
[   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
[   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;





Then rmqueue() checks for order > 1 and GFP_NOFAIL


static inline
struct page *rmqueue(struct zone *preferred_zone,
                         struct zone *zone, unsigned int order,
                         gfp_t gfp_flags, unsigned int alloc_flags,
                         int migratetype)
{
         struct page *page;

         /*
          * We most definitely don't want callers attempting to
          * allocate greater than order-1 page units with __GFP_NOFAIL.
          */
         WARN_ON_ONCE((gfp_flags & __GFP_NOFAIL) && (order > 1));





             reply	other threads:[~2023-11-01  0:14 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-01  0:13 Christoph Lameter (Ampere) [this message]
2023-11-01  8:08 ` Matthew Wilcox
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=6b42243e-f197-600a-5d22-56bd728a5ad8@gentwo.org \
    --to=cl@gentwo.org \
    --cc=linux-mm@kvack.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox