On Sat, Jul 04, 2020 at 02:49:32PM +0300, Pekka Enberg wrote: > Hi Matthew, > > On Sat, Jul 4, 2020 at 2:37 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote: > > > > On Sat, Jul 04, 2020 at 01:21:05AM -0600, Chris Murphy wrote: > > > Hi, > > > > > > This seems to be a one off - I'm not even sure what was happening at > > > the time. Possibly running a qemu-kvm VM. > > > > > > 5.8.0-0.rc3.1.fc33.x86_64+debug > > > i7-2820QM > > > MemTotal: 8021304 kB > > > $ swapon > > > NAME TYPE SIZE USED PRIO > > > /dev/sda5 partition 10.4G 0B -2 > > > /dev/zram0 partition 3.8G 9M 100 > > > $ zramctl > > > NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT > > > /dev/zram0 lzo-rle 3.8G 7.8M 2.3M 4.5M 8 [SWAP] > > > > > > > > > > > > > > > [126841.385050] swapper/2: page allocation failure: order:0, > > > mode:0x40810(GFP_NOWAIT|__GFP_COMP|__GFP_RECLAIMABLE), > > > > This is one for Dan; he decided to use GFP_NOWAIT in commit > > 0abdd7a81b7e3fd781d7fabcca49501852bba17e > > Why is that a problem? Unless I am missing something, there's plenty > of free pages available for the slab allocation: > > > > [126841.385277] Node 0 Normal: 366*4kB (UME) 413*8kB (UME) 76*16kB > > > (UME) 18*32kB (UME) 20*64kB (UME) 16*128kB (UME) 10*256kB (UME) > > > 8*512kB (ME) 5*1024kB (UE) 2*2048kB (UM) 6*4096kB (M) = 50336kB One of the things we (mostly Mike Kravetz) found recently when debugging a memory allocation stall issue is that this message does not capture the state which actually caused the message to be printed. In the intervening time between the memory allocation failure being detected and this message being printed, kswapd may have made forward progress.
