From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.9 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1,USER_IN_DEF_DKIM_WL autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BB66CC433DF for ; Mon, 8 Jun 2020 21:34:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 40020206D5 for ; Mon, 8 Jun 2020 21:34:01 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="JvMrgaB5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 40020206D5 Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 9DEB36B0002; Mon, 8 Jun 2020 17:34:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 98E446B0005; Mon, 8 Jun 2020 17:34:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8819D6B0006; Mon, 8 Jun 2020 17:34:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0042.hostedemail.com [216.40.44.42]) by kanga.kvack.org (Postfix) with ESMTP id 70C406B0002 for ; Mon, 8 Jun 2020 17:34:00 -0400 (EDT) Received: from smtpin06.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 24167B2E80 for ; Mon, 8 Jun 2020 21:34:00 +0000 (UTC) X-FDA: 76907347440.06.year44_5b170f426dbd Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin06.hostedemail.com (Postfix) with ESMTP id EE02510148461 for ; Mon, 8 Jun 2020 21:33:59 +0000 (UTC) X-HE-Tag: year44_5b170f426dbd X-Filterd-Recvd-Size: 10665 Received: from mail-oi1-f194.google.com (mail-oi1-f194.google.com [209.85.167.194]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Mon, 8 Jun 2020 21:33:59 +0000 (UTC) Received: by mail-oi1-f194.google.com with SMTP id a3so4776087oid.4 for ; Mon, 08 Jun 2020 14:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=4dvaDiP7i/gDWIh8qU49WM2i89mU0oMhpOLY6VMuBH8=; b=JvMrgaB5MKaBIgE2ahF2HJ8l5G3YK1Rp24Fg9/0fTHoenMBIv5mXGXXn5ziJm8fJ9+ YLg8hw5sJ+GBLsixHcafNrHXNyZG3Q4IMeaFnZPZqzJK1wfdSW9LLFDSpCbl8eBLWB4t 4YoQxksxl1ompB71JzQ6/4kkT4t9S5VTIaP96znEXfULBCd1b86Rq20M1knN6jj4ESE6 3Av//f6zd19YxedrICeA6KSYIQ1ItrrKQl1/6lqFNLJMErFZdZeFRYSM+DBHFpk87r7A 6ymsOgQWF22fiaoxUEM7ldo/brzn3/nVPIrRxmt1TG/nFbBxGMBrp3dl4n2f5D0VlztR rJow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=4dvaDiP7i/gDWIh8qU49WM2i89mU0oMhpOLY6VMuBH8=; b=R0bhE8ERPopGTpUndIYcHAU4xBxBPO38RVTttWLc3CfzkQOIvqmUP3IXPr9+rFbWvk 1mDLHY7licKqj6qYsOxn7c/sKN942WHUdwqO18ajVQ4jbZExmeYH9GyBOVe62miBAagQ eISqLfNDR1K1urfIQcrFyczsaKnfLGWf0xLJd2IrTp4buOnnKI0yhOmQStzcXtq1WFEo RTBJyYALHgyuVI48i0kPiWaWab5qDysTU4SkTnXR2GRfy01ltw40wi9StUp+kBBDL9cO wU/HFpLjAQlCjiXeEVBeinszGY3/SaiHTTruoSaWp1Zcw7b5tBUgYjoufmcwNW1BJEkf G4Yw== X-Gm-Message-State: AOAM531ZJ90mj9OpDaM94cVm0rhGGbNLHsS9KX97nXH8KZj6t3QdNLn0 c+XvUQU1HwCM3x6HKvM+dR3pNg== X-Google-Smtp-Source: ABdhPJw/F7J1r7ZbUTMrSLVCQ39CzPWlaO+1N8nV229ymMa3EROQA+wIYb2tWjEppua4H+ctcZe7jA== X-Received: by 2002:aca:dfc1:: with SMTP id w184mr1052066oig.113.1591652038450; Mon, 08 Jun 2020 14:33:58 -0700 (PDT) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id d128sm2582053oob.6.2020.06.08.14.33.56 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Mon, 08 Jun 2020 14:33:57 -0700 (PDT) Date: Mon, 8 Jun 2020 14:33:08 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Matthew Wilcox cc: Vlastimil Babka , Chris Murphy , Linux Memory Management List , Chris Wilson , Hugh Dickins Subject: Re: 5.7.0 page allocation failure: order:0, mode:0x400d0 In-Reply-To: <20200608114445.GT19604@bombadil.infradead.org> Message-ID: References: <20200606151254.GO19604@bombadil.infradead.org> <20200608114445.GT19604@bombadil.infradead.org> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Rspamd-Queue-Id: EE02510148461 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 #include +#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);