linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* Re: [Bug 208085] New: page allocation failure: order:0, mode:0x400d0
       [not found] <bug-208085-27@https.bugzilla.kernel.org/>
@ 2020-06-08  0:42 ` Andrew Morton
  2020-06-08  2:30   ` Chris Murphy
  0 siblings, 1 reply; 2+ messages in thread
From: Andrew Morton @ 2020-06-08  0:42 UTC (permalink / raw)
  To: linux-mm; +Cc: bugzilla-daemon, bugzilla, Matthew Wilcox

On Sat, 06 Jun 2020 07:25:40 +0000 bugzilla-daemon@bugzilla.kernel.org wrote:

> https://bugzilla.kernel.org/show_bug.cgi?id=208085
> 
>             Bug ID: 208085
>            Summary: page allocation failure: order:0, mode:0x400d0
>            Product: Memory Management
>            Version: 2.5
>     Kernel Version: 5.7.0-1.fc33.x86_64
>           Hardware: x86-64
>                 OS: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: Page Allocator
>           Assignee: akpm@linux-foundation.org
>           Reporter: bugzilla@colorremedies.com
>         Regression: No
> 
> i7-2820QM
> MemTotal:        8052740 kB
> SwapTotal:      14908572 kB
> $ swapon
> NAME       TYPE       SIZE USED PRIO
> /dev/sda5  partition 10.4G 4.4M   -2
> /dev/zram0 partition  3.9G 241M    3
> 
> 
> I'm seeing a new problem with kernel 5.7.0 I haven't previously seen.

Which previous kernel version(s) were OK?

> I am
> testing both swap on /dev/zram and swap on a partition. Two swaps. The workload
> is compiling webkitgtk with defaults, which is slightly overcommitted for the
> resources. I'm actually expecting better than 50% chance of OOM. But that's not
> what happens. After about 2 hours the whole thing just splats, and keeps
> splatting. Pretty weird.

Yes, this shouldn't happen.  Lots of anonymous memory, lots of free
swap yet the kernel declared oom.

We're in add_to_swap_cache() trying to allocate xarray metadata so
obviously we can't perform any reclaiming in this context.  I'd have
thought that in this situation we should permit xarray to dip into page
reserves.  But this is pretty old code (mainly 2017) and I don't think
we've done much to perturb it in 5.7, hence my above question.


[ 5225.501756] gnome-shell: page allocation failure: order:0, mode:0x400d0(__GFP_IO|__GFP_FS|__GFP_COMP|__GFP_RECLAIMABLE), nodemask=(null),cpuset=/,mems_allowed=0
[ 5225.501763] CPU: 2 PID: 1155 Comm: gnome-shell Not tainted 5.7.0-1.fc33.x86_64 #1
[ 5225.501764] Hardware name: Apple Inc. MacBookPro8,2/Mac-94245A3940C91C80, BIOS    MBP81.88Z.0050.B00.1804101331 04/10/18
[ 5225.501765] Call Trace:
[ 5225.501774]  dump_stack+0x64/0x88
[ 5225.501777]  warn_alloc.cold+0x75/0xd9
[ 5225.501781]  __alloc_pages_slowpath.constprop.0+0xcfa/0xd30
[ 5225.501785]  ? alloc_slab_page+0x195/0x310
[ 5225.501786]  __alloc_pages_nodemask+0x2df/0x320
[ 5225.501787]  alloc_slab_page+0x195/0x310
[ 5225.501789]  allocate_slab+0x3c5/0x440
[ 5225.501791]  ___slab_alloc+0x40c/0x5f0
[ 5225.501793]  ? xas_nomem+0x28/0x70
[ 5225.501795]  ? xas_alloc+0x9b/0xc0
[ 5225.501797]  ? xas_nomem+0x28/0x70
[ 5225.501798]  __slab_alloc+0x1c/0x30
[ 5225.501800]  kmem_cache_alloc+0x20e/0x220
[ 5225.501802]  xas_nomem+0x28/0x70
[ 5225.501803]  add_to_swap_cache+0x321/0x400
[ 5225.501806]  __read_swap_cache_async+0x105/0x240
[ 5225.501808]  swap_cluster_readahead+0x22c/0x2e0
[ 5225.501811]  shmem_swapin+0x8e/0xc0
[ 5225.501812]  ? kmem_cache_free+0x174/0x190
[ 5225.501814]  ? xas_store+0x33a/0x5e0
[ 5225.501817]  shmem_swapin_page+0x196/0x740
[ 5225.501819]  shmem_getpage_gfp+0x3a2/0xa60
[ 5225.501822]  shmem_read_mapping_page_gfp+0x32/0x60
[ 5225.501868]  shmem_get_pages+0x155/0x5e0 [i915]
[ 5225.501874]  ? __queue_work+0x1e3/0x410
[ 5225.501897]  ? add_hole+0x115/0x170 [drm]
[ 5225.501927]  ? fence_notify+0x86/0x104 [i915]
[ 5225.501954]  ? __i915_sw_fence_complete+0x10f/0x1c0 [i915]
[ 5225.501987]  __i915_gem_object_get_pages+0x68/0xa0 [i915]
[ 5225.502022]  i915_vma_pin+0x3fe/0x6c0 [i915]
[ 5225.502056]  eb_add_vma+0x10b/0x2c0 [i915]
[ 5225.502089]  i915_gem_do_execbuffer+0x704/0x3430 [i915]
[ 5225.502094]  ? blk_account_io_start+0xda/0x140
[ 5225.502096]  ? bio_attempt_back_merge+0x83/0xe0
[ 5225.502098]  ? blk_attempt_plug_merge+0x10c/0x110
[ 5225.502102]  ? bfq_update_fin_time_enqueue+0x13d/0x1a0
[ 5225.502106]  ? idling_needed_for_service_guarantees+0x3f/0x70
[ 5225.502108]  ? bfq_better_to_idle+0x73/0x90
[ 5225.502110]  ? bfq_dispatch_request+0x6ce/0x1070
[ 5225.502113]  ? bfq_add_bfqq_busy+0xa1/0x162
[ 5225.502117]  ? __blk_mq_run_hw_queue+0x49/0x110
[ 5225.502121]  ? __alloc_pages_slowpath.constprop.0+0x15b/0xd30
[ 5225.502124]  ? generic_end_io_acct+0x91/0xf0
[ 5225.502127]  ? sched_clock+0x5/0x10
[ 5225.502131]  ? sched_clock_cpu+0xc/0xa0
[ 5225.502134]  ? _cond_resched+0x16/0x40
[ 5225.502136]  ? __kmalloc_node+0x204/0x300
[ 5225.502168]  ? i915_gem_execbuffer2_ioctl+0x93/0x3e0 [i915]
[ 5225.502201]  i915_gem_execbuffer2_ioctl+0x1ea/0x3e0 [i915]
[ 5225.502204]  ? reuse_swap_page+0x8c/0x380
[ 5225.502238]  ? i915_gem_execbuffer_ioctl+0x2a0/0x2a0 [i915]
[ 5225.502253]  drm_ioctl_kernel+0x86/0xd0 [drm]
[ 5225.502257]  ? avc_has_perm+0x3b/0x160
[ 5225.502272]  drm_ioctl+0x206/0x390 [drm]
[ 5225.502306]  ? i915_gem_execbuffer_ioctl+0x2a0/0x2a0 [i915]
[ 5225.502311]  ksys_ioctl+0x82/0xc0
[ 5225.502313]  __x64_sys_ioctl+0x16/0x20
[ 5225.502317]  do_syscall_64+0x5b/0xf0
[ 5225.502320]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 5225.502323] RIP: 0033:0x7ff76292047b
[ 5225.502326] Code: 0f 1e fa 48 8b 05 1d aa 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ed a9 0c 00 f7 d8 64 89 01 48
[ 5225.502328] RSP: 002b:00007fff75aed128 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 5225.502330] RAX: ffffffffffffffda RBX: 00007fff75aed170 RCX: 00007ff76292047b
[ 5225.502332] RDX: 00007fff75aed170 RSI: 0000000040406469 RDI: 000000000000000d
[ 5225.502334] RBP: 0000000040406469 R08: 000000000000000d R09: 000055ff644b09a0
[ 5225.502335] R10: 0000000000000000 R11: 0000000000000246 R12: 000055ff6446c760
[ 5225.502336] R13: 000000000000000d R14: ffffffffffffffff R15: 00007ff74af22828
[ 5225.502339] Mem-Info:
[ 5225.502345] active_anon:1433763 inactive_anon:207289 isolated_anon:182
                active_file:10333 inactive_file:8393 isolated_file:2
                unevictable:4657 dirty:100 writeback:0 unstable:0
                slab_reclaimable:16672 slab_unreclaimable:38093
                mapped:8919 shmem:4496 pagetables:10454 bounce:0
                free:26161 free_pcp:2054 free_cma:0
[ 5225.502350] Node 0 active_anon:5735052kB inactive_anon:829156kB active_file:41332kB inactive_file:33572kB unevictable:18628kB isolated(anon):728kB isolated(file):8kB mapped:35676kB dirty:400kB writeback:0kB shmem:17984kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 0kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no
[ 5225.502352] Node 0 DMA free:15344kB min:128kB low:160kB high:192kB reserved_highatomic:0KB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15988kB managed:15360kB mlocked:0kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB
[ 5225.502357] lowmem_reserve[]: 0 2069 7810 7810 7810
[ 5225.502360] Node 0 DMA32 free:40212kB min:17868kB low:22332kB high:26796kB reserved_highatomic:0KB active_anon:1640016kB inactive_anon:265148kB active_file:9856kB inactive_file:12584kB unevictable:2968kB writepending:136kB present:2255864kB managed:2157904kB mlocked:0kB kernel_stack:48kB pagetables:8524kB bounce:0kB free_pcp:2904kB local_pcp:156kB free_cma:0kB
[ 5225.502365] lowmem_reserve[]: 0 0 5741 5741 5741
[ 5225.502368] Node 0 Normal free:49088kB min:49584kB low:61980kB high:74376kB reserved_highatomic:2048KB active_anon:4098076kB inactive_anon:563004kB active_file:32212kB inactive_file:21312kB unevictable:13680kB writepending:0kB present:6027264kB managed:5879476kB mlocked:1792kB kernel_stack:7312kB pagetables:33292kB bounce:0kB free_pcp:5388kB local_pcp:780kB free_cma:0kB
[ 5225.502373] lowmem_reserve[]: 0 0 0 0 0
[ 5225.502376] Node 0 DMA: 0*4kB 0*8kB 1*16kB (U) 1*32kB (U) 1*64kB (U) 1*128kB (U) 1*256kB (U) 1*512kB (U) 0*1024kB 1*2048kB (M) 3*4096kB (M) = 15344kB
[ 5225.502385] Node 0 DMA32: 1160*4kB (UM) 471*8kB (UME) 84*16kB (UM) 103*32kB (UME) 116*64kB (UME) 59*128kB (UME) 26*256kB (UE) 8*512kB (E) 2*1024kB (E) 0*2048kB 0*4096kB = 40824kB
[ 5225.502394] Node 0 Normal: 4778*4kB (UMH) 1400*8kB (UMEH) 346*16kB (UMH) 270*32kB (UMEH) 20*64kB (UMEH) 20*128kB (MEH) 4*256kB (MEH) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 49352kB
[ 5225.502404] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB
[ 5225.502405] 114228 total pagecache pages
[ 5225.502408] 90616 pages in swap cache
[ 5225.502410] Swap cache stats: add 52638812, delete 52548141, find 2182667/30436788
[ 5225.502411] Free swap  = 5921200kB
[ 5225.502413] Total swap = 14908572kB
[ 5225.502414] 2074779 pages RAM
[ 5225.502415] 0 pages HighMem/MovableOnly
[ 5225.502416] 61594 pages reserved
[ 5225.502417] 0 pages cma reserved
[ 5225.502418] 0 pages hwpoisoned
[ 5225.502420] SLUB: Unable to allocate memory on node -1, gfp=0xc0(__GFP_IO|__GFP_FS)
[ 5225.502422]   cache: radix_tree_node, object size: 576, buffer size: 584, default order: 2, min order: 0
[ 5225.502424]   node 0: slabs: 654, objs: 11886, free: 0



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [Bug 208085] New: page allocation failure: order:0, mode:0x400d0
  2020-06-08  0:42 ` [Bug 208085] New: page allocation failure: order:0, mode:0x400d0 Andrew Morton
@ 2020-06-08  2:30   ` Chris Murphy
  0 siblings, 0 replies; 2+ messages in thread
From: Chris Murphy @ 2020-06-08  2:30 UTC (permalink / raw)
  To: Linux Memory Management List; +Cc: Matthew Wilcox, Andrew Morton

On Sun, Jun 7, 2020 at 6:42 PM Andrew Morton <akpm@linux-foundation.org> wrote:
>
> > I'm seeing a new problem with kernel 5.7.0 I haven't previously seen.
>
> Which previous kernel version(s) were OK?

With swaponzram or swapondisk by separately - 5.6.13. Same webkitgtk test.

Together? It's been maybe since 5.3 series since I tried it.

This took about 2 hours to hit. I know the kernel supports up to 32
swaps since forever, but I don't know that this is very common, so I
wonder if it's related to two swaps or the fact one is zram based.



-- 
Chris Murphy


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-06-08  2:30 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-208085-27@https.bugzilla.kernel.org/>
2020-06-08  0:42 ` [Bug 208085] New: page allocation failure: order:0, mode:0x400d0 Andrew Morton
2020-06-08  2:30   ` Chris Murphy

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).