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