* 5.7.0 page allocation failure: order:0, mode:0x400d0 @ 2020-06-06 7:38 Chris Murphy 2020-06-06 15:12 ` Matthew Wilcox 0 siblings, 1 reply; 14+ messages in thread From: Chris Murphy @ 2020-06-06 7:38 UTC (permalink / raw) To: Linux Memory Management List Hi, I'm seeing a new problem with kernel 5.7.0 I haven't previously seen. 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 oom. But that's not what happens. After about 2 hours the whole thing just splats. Bug report here with dmesg and meminfo attached. Partial below. https://bugzilla.kernel.org/show_bug.cgi?id=208085 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 $ There are multiple splats, this is one of them. [ 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 -- Chris Murphy ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 5.7.0 page allocation failure: order:0, mode:0x400d0 2020-06-06 7:38 5.7.0 page allocation failure: order:0, mode:0x400d0 Chris Murphy @ 2020-06-06 15:12 ` Matthew Wilcox 2020-06-07 0:50 ` Chris Murphy 2020-06-08 9:08 ` Vlastimil Babka 0 siblings, 2 replies; 14+ messages in thread From: Matthew Wilcox @ 2020-06-06 15:12 UTC (permalink / raw) To: Chris Murphy; +Cc: Linux Memory Management List On Sat, Jun 06, 2020 at 01:38:57AM -0600, Chris Murphy wrote: > [ 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 These are relatively liberal constraints on what the page allocator is allowed to do in order to succeed. > [ 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.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.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 Oh, cool. We're trying to allocate a node to store a page in the swap cache. > [ 5225.501806] __read_swap_cache_async+0x105/0x240 > [ 5225.501808] swap_cluster_readahead+0x22c/0x2e0 > [ 5225.501811] shmem_swapin+0x8e/0xc0 ... while trying to read a page back in from swap. > [ 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] ... that was written out by shmem (so not an anonymous page). > [ 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 Umm ... seems like there's lots of memory free. Why did this fail? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 5.7.0 page allocation failure: order:0, mode:0x400d0 2020-06-06 15:12 ` Matthew Wilcox @ 2020-06-07 0:50 ` Chris Murphy 2020-06-08 9:08 ` Vlastimil Babka 1 sibling, 0 replies; 14+ messages in thread From: Chris Murphy @ 2020-06-07 0:50 UTC (permalink / raw) To: Matthew Wilcox; +Cc: Chris Murphy, Linux Memory Management List On Sat, Jun 6, 2020 at 9:12 AM Matthew Wilcox <willy@infradead.org> wrote: > > On Sat, Jun 06, 2020 at 01:38:57AM -0600, Chris Murphy wrote: > > [ 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 > > These are relatively liberal constraints on what the page allocator is > allowed to do in order to succeed. > > > [ 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.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.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 > > Oh, cool. We're trying to allocate a node to store a page in the swap cache. > > > [ 5225.501806] __read_swap_cache_async+0x105/0x240 > > [ 5225.501808] swap_cluster_readahead+0x22c/0x2e0 > > [ 5225.501811] shmem_swapin+0x8e/0xc0 > > ... while trying to read a page back in from swap. > > > [ 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] > > ... that was written out by shmem (so not an anonymous page). > > > [ 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 > > Umm ... seems like there's lots of memory free. Why did this fail? Haha, hopefully this is not a question for me. But if a Fedora debug kernel will reveal more info I can retry. Let me know if it needs any debug kernel parameters. -- Chris Murphy ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 5.7.0 page allocation failure: order:0, mode:0x400d0 2020-06-06 15:12 ` Matthew Wilcox 2020-06-07 0:50 ` Chris Murphy @ 2020-06-08 9:08 ` Vlastimil Babka 2020-06-08 11:44 ` Matthew Wilcox 1 sibling, 1 reply; 14+ messages in thread From: Vlastimil Babka @ 2020-06-08 9:08 UTC (permalink / raw) To: Matthew Wilcox, Chris Murphy; +Cc: Linux Memory Management List On 6/6/20 5:12 PM, Matthew Wilcox wrote: > On Sat, Jun 06, 2020 at 01:38:57AM -0600, Chris Murphy wrote: >> [ 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 > > These are relatively liberal constraints on what the page allocator is > allowed to do in order to succeed. They are not, it's not allowed to reclaim at all - __GFP_RECLAIMABLE is not the same thing as __GFP_RECLAIM :) AFAICS the masks starts in shmem_gfp_pages() * Fail silently without starting the shrinker noreclaim = mapping_gfp_constraint(mapping, ~__GFP_RECLAIM); noreclaim |= __GFP_NORETRY | __GFP_NOWARN; possibly mapping has GFP_KERNEL, but this removes the GFP_RECLAIM part and adds __GFP_NORETRY | __GFP_NOWARN if this fails (silently) there's a fallback But when this reaches __read_swap_cache_async() it does: /* May fail (-ENOMEM) if XArray node allocation failed. */ err = add_to_swap_cache(new_page, entry, gfp_mask & GFP_KERNEL); So we lose the __GFP_NORETRY and importantly __GFP_NOWARN. Looks like you added that with commit 8d93b41c09d1b :) ... >> [ 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 > > Umm ... seems like there's lots of memory free. Why did this fail? Normal is below min watermark, and for DMA32 and DMA the lowmem reserve most likely kicked in. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 5.7.0 page allocation failure: order:0, mode:0x400d0 2020-06-08 9:08 ` Vlastimil Babka @ 2020-06-08 11:44 ` Matthew Wilcox 2020-06-08 21:33 ` Hugh Dickins 0 siblings, 1 reply; 14+ messages in thread From: Matthew Wilcox @ 2020-06-08 11:44 UTC (permalink / raw) To: Vlastimil Babka Cc: Chris Murphy, Linux Memory Management List, Chris Wilson, Hugh Dickins On Mon, Jun 08, 2020 at 11:08:33AM +0200, Vlastimil Babka wrote: > On 6/6/20 5:12 PM, Matthew Wilcox wrote: > > On Sat, Jun 06, 2020 at 01:38:57AM -0600, Chris Murphy wrote: > >> [ 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 > > > > These are relatively liberal constraints on what the page allocator is > > allowed to do in order to succeed. > > They are not, it's not allowed to reclaim at all - __GFP_RECLAIMABLE is not the > same thing as __GFP_RECLAIM :) Ohh, __GFP_RECLAIMABLE is set because it's an XArray allocation and the slab can shrink the xarray nodes (by pruning page cache shadow entries), but __GFP_RECLAIM isn't set because shmem_gfp_pages() removes it. So slab is saying "you can reclaim", but shmem is saying "not in this context". > AFAICS the masks starts in shmem_gfp_pages() Ah! You mean in i915's shmem_get_pages(). > * Fail silently without starting the shrinker > noreclaim = mapping_gfp_constraint(mapping, ~__GFP_RECLAIM); > noreclaim |= __GFP_NORETRY | __GFP_NOWARN; > > possibly mapping has GFP_KERNEL, but this removes the GFP_RECLAIM part and adds > __GFP_NORETRY | __GFP_NOWARN > > if this fails (silently) there's a fallback > > But when this reaches __read_swap_cache_async() it does: > > /* May fail (-ENOMEM) if XArray node allocation failed. */ > err = add_to_swap_cache(new_page, entry, gfp_mask & GFP_KERNEL); > > So we lose the __GFP_NORETRY and importantly __GFP_NOWARN. Looks like you added > that with commit 8d93b41c09d1b :) I just moved code around: - /* - * call radix_tree_preload() while we can wait. - */ - err = radix_tree_maybe_preload(gfp_mask & GFP_KERNEL); - if (err) - break; so this problem could have occurred without this patch. Yes, it seems to me that the problem is that i915 set GFP_NOWARN and swap_state removed it. It's been this way since 2008 when Hugh committed f000944d03a5 I wouldn't have a problem with turning that '& GFP_KERNEL' into '& GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY'. i915 has been using __GFP_NOWARN | __GFP_NORETRY in this path since 2012 (!) with commit 6c085a728cf0 from Chris Wilson. So I guess we just got away with it until now? Adding Chris & Hugh. > ... > > >> [ 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 > > > > Umm ... seems like there's lots of memory free. Why did this fail? > > Normal is below min watermark, and for DMA32 and DMA the lowmem reserve most > likely kicked in. > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 5.7.0 page allocation failure: order:0, mode:0x400d0 2020-06-08 11:44 ` Matthew Wilcox @ 2020-06-08 21:33 ` Hugh Dickins 2020-06-09 2:01 ` Matthew Wilcox ` (2 more replies) 0 siblings, 3 replies; 14+ messages in thread From: Hugh Dickins @ 2020-06-08 21:33 UTC (permalink / raw) To: Matthew Wilcox Cc: Vlastimil Babka, Chris Murphy, Linux Memory Management List, Chris Wilson, Hugh Dickins On Mon, 8 Jun 2020, Matthew Wilcox wrote: > On Mon, Jun 08, 2020 at 11:08:33AM +0200, Vlastimil Babka wrote: > > On 6/6/20 5:12 PM, Matthew Wilcox wrote: > > > On Sat, Jun 06, 2020 at 01:38:57AM -0600, Chris Murphy wrote: > > >> [ 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 > > > > > > These are relatively liberal constraints on what the page allocator is > > > allowed to do in order to succeed. > > > > They are not, it's not allowed to reclaim at all - __GFP_RECLAIMABLE is not the > > same thing as __GFP_RECLAIM :) > > Ohh, __GFP_RECLAIMABLE is set because it's an XArray allocation and the > slab can shrink the xarray nodes (by pruning page cache shadow entries), > but __GFP_RECLAIM isn't set because shmem_gfp_pages() removes it. So slab > is saying "you can reclaim", but shmem is saying "not in this context". > > > AFAICS the masks starts in shmem_gfp_pages() > > Ah! You mean in i915's shmem_get_pages(). Yes, it is surprising to find shmem_get_pages() over there. It's static, but still confusing. ChrisW, any chance that your shmem_get_pages() could be renamed i915_gem_shmem_get_pages(), and similarly the several other shmem_* functions in there? > > > * Fail silently without starting the shrinker > > noreclaim = mapping_gfp_constraint(mapping, ~__GFP_RECLAIM); > > noreclaim |= __GFP_NORETRY | __GFP_NOWARN; > > > > possibly mapping has GFP_KERNEL, but this removes the GFP_RECLAIM part and adds > > __GFP_NORETRY | __GFP_NOWARN > > > > if this fails (silently) there's a fallback > > > > But when this reaches __read_swap_cache_async() it does: > > > > /* May fail (-ENOMEM) if XArray node allocation failed. */ > > err = add_to_swap_cache(new_page, entry, gfp_mask & GFP_KERNEL); > > > > So we lose the __GFP_NORETRY and importantly __GFP_NOWARN. Looks like you added > > that with commit 8d93b41c09d1b :) > > I just moved code around: > > - /* > - * call radix_tree_preload() while we can wait. > - */ > - err = radix_tree_maybe_preload(gfp_mask & GFP_KERNEL); > - if (err) > - break; > > so this problem could have occurred without this patch. > > Yes, it seems to me that the problem is that i915 set GFP_NOWARN and > swap_state removed it. It's been this way since 2008 when Hugh committed > f000944d03a5 > > I wouldn't have a problem with turning that '& GFP_KERNEL' into > '& GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY'. Yes, I'd be fine with that too (with some parentheses perhaps). Or (looking at what you used in __add_to_page_cache_locked()), would "gfp_mask & GFP_RECLAIM_MASK" be better? I think so, and guess you'd be glad to follow your own precedent. Quiz question: where would you expect GFP_RECLAIM_MASK to be defined? ChrisM, could you try with the patch below, and see if it works for you - I hope it doesn't just give you a blank screen. I've often wondered whether the swapin readaheads would do better to pass in such flags on all but the one page required - but that's a separate matter. > > i915 has been using __GFP_NOWARN | __GFP_NORETRY in this path since 2012 > (!) with commit 6c085a728cf0 from Chris Wilson. So I guess we just > got away with it until now? I tried, but haven't found a convincing explanation. Is i915 putting more pressure on now in this setup, perhaps? > > Adding Chris & Hugh. > > > ... > > > > >> [ 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 > > > > > > Umm ... seems like there's lots of memory free. Why did this fail? > > > > Normal is below min watermark, and for DMA32 and DMA the lowmem reserve most > > likely kicked in. --- 5.7.0/mm/swap_state.c 2020-05-31 16:49:15.000000000 -0700 +++ linux/mm/swap_state.c 2020-06-08 14:27:38.211813658 -0700 @@ -23,6 +23,7 @@ #include <linux/huge_mm.h> #include <asm/pgtable.h> +#include "internal.h" /* * swapper_space is a fiction, retained to simplify the path through @@ -418,7 +419,8 @@ struct page *__read_swap_cache_async(swp /* May fail (-ENOMEM) if XArray node allocation failed. */ __SetPageLocked(new_page); __SetPageSwapBacked(new_page); - err = add_to_swap_cache(new_page, entry, gfp_mask & GFP_KERNEL); + err = add_to_swap_cache(new_page, entry, + gfp_mask & GFP_RECLAIM_MASK); if (likely(!err)) { /* Initiate read into locked page */ SetPageWorkingset(new_page); ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 5.7.0 page allocation failure: order:0, mode:0x400d0 2020-06-08 21:33 ` Hugh Dickins @ 2020-06-09 2:01 ` Matthew Wilcox 2020-06-10 15:21 ` Chris Murphy 2020-06-10 23:31 ` Chris Murphy 2 siblings, 0 replies; 14+ messages in thread From: Matthew Wilcox @ 2020-06-09 2:01 UTC (permalink / raw) To: Hugh Dickins Cc: Vlastimil Babka, Chris Murphy, Linux Memory Management List, Chris Wilson On Mon, Jun 08, 2020 at 02:33:08PM -0700, Hugh Dickins wrote: > On Mon, 8 Jun 2020, Matthew Wilcox wrote: > > On Mon, Jun 08, 2020 at 11:08:33AM +0200, Vlastimil Babka wrote: > > > * Fail silently without starting the shrinker > > > noreclaim = mapping_gfp_constraint(mapping, ~__GFP_RECLAIM); > > > noreclaim |= __GFP_NORETRY | __GFP_NOWARN; > > > > > > possibly mapping has GFP_KERNEL, but this removes the GFP_RECLAIM part and adds > > > __GFP_NORETRY | __GFP_NOWARN > > > > > > if this fails (silently) there's a fallback > > > > > > But when this reaches __read_swap_cache_async() it does: > > > > > > /* May fail (-ENOMEM) if XArray node allocation failed. */ > > > err = add_to_swap_cache(new_page, entry, gfp_mask & GFP_KERNEL); > > > > Yes, it seems to me that the problem is that i915 set GFP_NOWARN and > > swap_state removed it. It's been this way since 2008 when Hugh committed > > f000944d03a5 > > > > I wouldn't have a problem with turning that '& GFP_KERNEL' into > > '& GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY'. > > Yes, I'd be fine with that too (with some parentheses perhaps). > > Or (looking at what you used in __add_to_page_cache_locked()), > would "gfp_mask & GFP_RECLAIM_MASK" be better? I think so, > and guess you'd be glad to follow your own precedent. Oh, again, I just moved code around. Even though I did put it in __add_to_page_cache_locked() with commit abc1be13fd11, I just moved it from pagecache_get_page(). The real hero here is commit 45f87de57f8f from Michael Hocko with honourable mention to commit dd56b0464267 by Mel Gorman. I always like to follow the precedent set in other places, and GFP_RECLAIM_MASK is exactly intended for this purpose. So yes, I think this is the perfect patch. > Quiz question: where would you expect GFP_RECLAIM_MASK to be defined? Heh. I don't think mm/internal.h is the right place for it either. I'd've put it in linux/gfp.h. > --- 5.7.0/mm/swap_state.c 2020-05-31 16:49:15.000000000 -0700 > +++ linux/mm/swap_state.c 2020-06-08 14:27:38.211813658 -0700 > @@ -23,6 +23,7 @@ > #include <linux/huge_mm.h> > > #include <asm/pgtable.h> > +#include "internal.h" > > /* > * swapper_space is a fiction, retained to simplify the path through > @@ -418,7 +419,8 @@ struct page *__read_swap_cache_async(swp > /* May fail (-ENOMEM) if XArray node allocation failed. */ > __SetPageLocked(new_page); > __SetPageSwapBacked(new_page); > - err = add_to_swap_cache(new_page, entry, gfp_mask & GFP_KERNEL); > + err = add_to_swap_cache(new_page, entry, > + gfp_mask & GFP_RECLAIM_MASK); > if (likely(!err)) { > /* Initiate read into locked page */ > SetPageWorkingset(new_page); > Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org> ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 5.7.0 page allocation failure: order:0, mode:0x400d0 2020-06-08 21:33 ` Hugh Dickins 2020-06-09 2:01 ` Matthew Wilcox @ 2020-06-10 15:21 ` Chris Murphy 2020-06-10 15:28 ` Chris Murphy 2020-06-10 23:31 ` Chris Murphy 2 siblings, 1 reply; 14+ messages in thread From: Chris Murphy @ 2020-06-10 15:21 UTC (permalink / raw) To: Hugh Dickins Cc: Matthew Wilcox, Vlastimil Babka, Chris Murphy, Linux Memory Management List, Chris Wilson On Mon, Jun 8, 2020 at 3:33 PM Hugh Dickins <hughd@google.com> wrote: > > ChrisM, could you try with the patch below, and see if it works > for you - I hope it doesn't just give you a blank screen. I can - however... > --- 5.7.0/mm/swap_state.c 2020-05-31 16:49:15.000000000 -0700 > +++ linux/mm/swap_state.c 2020-06-08 14:27:38.211813658 -0700 > @@ -23,6 +23,7 @@ > #include <linux/huge_mm.h> > > #include <asm/pgtable.h> > +#include "internal.h" $ git status On branch test57rc7gcc10001 nothing to commit, working tree clean $ grep pgtable mm/swap_state.c $ I'm missing something. And there's more... > > /* > * swapper_space is a fiction, retained to simplify the path through > @@ -418,7 +419,8 @@ struct page *__read_swap_cache_async(swp > /* May fail (-ENOMEM) if XArray node allocation failed. */ > __SetPageLocked(new_page); > __SetPageSwapBacked(new_page); > - err = add_to_swap_cache(new_page, entry, gfp_mask & GFP_KERNEL); > + err = add_to_swap_cache(new_page, entry, > + gfp_mask & GFP_RECLAIM_MASK); > if (likely(!err)) { > /* Initiate read into locked page */ > SetPageWorkingset(new_page); Neither the line above or below this insertion match what I have. 424 /* 425 * The swap entry is ours to swap in. Prepare the new page. 426 */ 427 428 __SetPageLocked(page); 429 __SetPageSwapBacked(page); 430 431 /* May fail (-ENOMEM) if XArray node allocation failed. */ 432 if (add_to_swap_cache(page, entry, gfp_mask & GFP_KERNEL)) { 433 put_swap_page(page, entry); 434 goto fail_unlock; 435 } -- Chris Murphy ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 5.7.0 page allocation failure: order:0, mode:0x400d0 2020-06-10 15:21 ` Chris Murphy @ 2020-06-10 15:28 ` Chris Murphy 0 siblings, 0 replies; 14+ messages in thread From: Chris Murphy @ 2020-06-10 15:28 UTC (permalink / raw) To: Chris Murphy Cc: Hugh Dickins, Matthew Wilcox, Vlastimil Babka, Linux Memory Management List, Chris Wilson On Wed, Jun 10, 2020 at 9:21 AM Chris Murphy <lists@colorremedies.com> wrote: > > On branch test57rc7gcc10001 Cute. User errors strike again... Didn't notice that when I copied it but noticed it right after I clicked send! Standby. I'll have a test in a few hours I guess, unless it blows up sooner. -- Chris Murphy ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 5.7.0 page allocation failure: order:0, mode:0x400d0 2020-06-08 21:33 ` Hugh Dickins 2020-06-09 2:01 ` Matthew Wilcox 2020-06-10 15:21 ` Chris Murphy @ 2020-06-10 23:31 ` Chris Murphy 2020-06-10 23:33 ` Matthew Wilcox 2 siblings, 1 reply; 14+ messages in thread From: Chris Murphy @ 2020-06-10 23:31 UTC (permalink / raw) To: Hugh Dickins Cc: Matthew Wilcox, Vlastimil Babka, Chris Murphy, Linux Memory Management List, Chris Wilson On Mon, Jun 8, 2020 at 3:33 PM Hugh Dickins <hughd@google.com> wrote: > > ChrisM, could you try with the patch below, and see if it works > for you - I hope it doesn't just give you a blank screen. Did this. Does compile, and boot, no blank screen, and webkitgtk compiles without error (it ends in OOM, as expected). > > > --- 5.7.0/mm/swap_state.c 2020-05-31 16:49:15.000000000 -0700 > +++ linux/mm/swap_state.c 2020-06-08 14:27:38.211813658 -0700 > @@ -23,6 +23,7 @@ > #include <linux/huge_mm.h> > > #include <asm/pgtable.h> > +#include "internal.h" > > /* > * swapper_space is a fiction, retained to simplify the path through > @@ -418,7 +419,8 @@ struct page *__read_swap_cache_async(swp > /* May fail (-ENOMEM) if XArray node allocation failed. */ > __SetPageLocked(new_page); > __SetPageSwapBacked(new_page); > - err = add_to_swap_cache(new_page, entry, gfp_mask & GFP_KERNEL); > + err = add_to_swap_cache(new_page, entry, > + gfp_mask & GFP_RECLAIM_MASK); > if (likely(!err)) { > /* Initiate read into locked page */ > SetPageWorkingset(new_page); -- Chris Murphy ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 5.7.0 page allocation failure: order:0, mode:0x400d0 2020-06-10 23:31 ` Chris Murphy @ 2020-06-10 23:33 ` Matthew Wilcox 2020-06-10 23:43 ` Chris Murphy 0 siblings, 1 reply; 14+ messages in thread From: Matthew Wilcox @ 2020-06-10 23:33 UTC (permalink / raw) To: Chris Murphy Cc: Hugh Dickins, Vlastimil Babka, Linux Memory Management List, Chris Wilson On Wed, Jun 10, 2020 at 05:31:14PM -0600, Chris Murphy wrote: > On Mon, Jun 8, 2020 at 3:33 PM Hugh Dickins <hughd@google.com> wrote: > > > > ChrisM, could you try with the patch below, and see if it works > > for you - I hope it doesn't just give you a blank screen. > > Did this. Does compile, and boot, no blank screen, and webkitgtk > compiles without error (it ends in OOM, as expected). ... but the OOM doesn't point back to i915's shmem functions any more? ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 5.7.0 page allocation failure: order:0, mode:0x400d0 2020-06-10 23:33 ` Matthew Wilcox @ 2020-06-10 23:43 ` Chris Murphy 2020-06-11 3:14 ` Chris Murphy 0 siblings, 1 reply; 14+ messages in thread From: Chris Murphy @ 2020-06-10 23:43 UTC (permalink / raw) To: Matthew Wilcox Cc: Chris Murphy, Hugh Dickins, Vlastimil Babka, Linux Memory Management List, Chris Wilson On Wed, Jun 10, 2020 at 5:33 PM Matthew Wilcox <willy@infradead.org> wrote: > > On Wed, Jun 10, 2020 at 05:31:14PM -0600, Chris Murphy wrote: > > On Mon, Jun 8, 2020 at 3:33 PM Hugh Dickins <hughd@google.com> wrote: > > > > > > ChrisM, could you try with the patch below, and see if it works > > > for you - I hope it doesn't just give you a blank screen. > > > > Did this. Does compile, and boot, no blank screen, and webkitgtk > > compiles without error (it ends in OOM, as expected). > > ... but the OOM doesn't point back to i915's shmem functions any more? It doesn't, but... I'm going to redo the test because Fedora Workstation 32 enables earlyoom by default, and that's what triggered the OOM. Not the kernel's oomkiller. But in the original report, earlyoom was also enabled but not triggered, yet I got the reported splats. -- Chris Murphy ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 5.7.0 page allocation failure: order:0, mode:0x400d0 2020-06-10 23:43 ` Chris Murphy @ 2020-06-11 3:14 ` Chris Murphy 2020-06-15 20:29 ` Hugh Dickins 0 siblings, 1 reply; 14+ messages in thread From: Chris Murphy @ 2020-06-11 3:14 UTC (permalink / raw) To: Chris Murphy Cc: Matthew Wilcox, Hugh Dickins, Vlastimil Babka, Linux Memory Management List, Chris Wilson On Wed, Jun 10, 2020 at 5:43 PM Chris Murphy <lists@colorremedies.com> wrote: > > On Wed, Jun 10, 2020 at 5:33 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > On Wed, Jun 10, 2020 at 05:31:14PM -0600, Chris Murphy wrote: > > > On Mon, Jun 8, 2020 at 3:33 PM Hugh Dickins <hughd@google.com> wrote: > > > > > > > > ChrisM, could you try with the patch below, and see if it works > > > > for you - I hope it doesn't just give you a blank screen. > > > > > > Did this. Does compile, and boot, no blank screen, and webkitgtk > > > compiles without error (it ends in OOM, as expected). > > > > ... but the OOM doesn't point back to i915's shmem functions any more? > > It doesn't, but... > > I'm going to redo the test because Fedora Workstation 32 enables > earlyoom by default, and that's what triggered the OOM. Not the > kernel's oomkiller. But in the original report, earlyoom was also > enabled but not triggered, yet I got the reported splats. Completes, no splats. (And no OOM.) -- Chris Murphy ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: 5.7.0 page allocation failure: order:0, mode:0x400d0 2020-06-11 3:14 ` Chris Murphy @ 2020-06-15 20:29 ` Hugh Dickins 0 siblings, 0 replies; 14+ messages in thread From: Hugh Dickins @ 2020-06-15 20:29 UTC (permalink / raw) To: Chris Murphy Cc: Matthew Wilcox, Hugh Dickins, Vlastimil Babka, Linux Memory Management List, Chris Wilson On Wed, 10 Jun 2020, Chris Murphy wrote: > On Wed, Jun 10, 2020 at 5:43 PM Chris Murphy <lists@colorremedies.com> wrote: > > On Wed, Jun 10, 2020 at 5:33 PM Matthew Wilcox <willy@infradead.org> wrote: > > > > > > On Wed, Jun 10, 2020 at 05:31:14PM -0600, Chris Murphy wrote: > > > > On Mon, Jun 8, 2020 at 3:33 PM Hugh Dickins <hughd@google.com> wrote: > > > > > > > > > > ChrisM, could you try with the patch below, and see if it works > > > > > for you - I hope it doesn't just give you a blank screen. > > > > > > > > Did this. Does compile, and boot, no blank screen, and webkitgtk > > > > compiles without error (it ends in OOM, as expected). > > > > > > ... but the OOM doesn't point back to i915's shmem functions any more? > > > > It doesn't, but... > > > > I'm going to redo the test because Fedora Workstation 32 enables > > earlyoom by default, and that's what triggered the OOM. Not the > > kernel's oomkiller. But in the original report, earlyoom was also > > enabled but not triggered, yet I got the reported splats. > > Completes, no splats. (And no OOM.) Great, thanks a lot for reporting and testing, Chris: patch coming up in reply to this - effectively the same as the patch you're using for 5.7 (and which we shall use for stable backports), but 5.8-rc1 looks a little different thereabouts. Hugh ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2020-06-15 20:30 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-06-06 7:38 5.7.0 page allocation failure: order:0, mode:0x400d0 Chris Murphy 2020-06-06 15:12 ` Matthew Wilcox 2020-06-07 0:50 ` Chris Murphy 2020-06-08 9:08 ` Vlastimil Babka 2020-06-08 11:44 ` Matthew Wilcox 2020-06-08 21:33 ` Hugh Dickins 2020-06-09 2:01 ` Matthew Wilcox 2020-06-10 15:21 ` Chris Murphy 2020-06-10 15:28 ` Chris Murphy 2020-06-10 23:31 ` Chris Murphy 2020-06-10 23:33 ` Matthew Wilcox 2020-06-10 23:43 ` Chris Murphy 2020-06-11 3:14 ` Chris Murphy 2020-06-15 20:29 ` Hugh Dickins
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).