Received: by 10.192.165.156 with SMTP id m28csp923551imm; Wed, 18 Apr 2018 00:21:30 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+HzQf0MXutXtsoLgaXvNtynSgjLvqgmYGfBYI11/Wozpp6B9hEGe8s6IocgSl/MfNlcfTz X-Received: by 10.167.130.151 with SMTP id s23mr975825pfm.106.1524036090219; Wed, 18 Apr 2018 00:21:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1524036090; cv=none; d=google.com; s=arc-20160816; b=xTETU5Oxk64jhhTQD09SSXnyrYj1D6L6c9tuUgaWClDj0GEL1D/rSqzkvQBAsgSNlw vq6puhaE/6u+hO/irLadv0QsHXQyQ+0fjdzfW9IR/J14Cx6cUu2VPx288dcPlgj8mDY0 QOZX4jnOs6ukwWmliRYNfbFVAULb4IzBe36X8CNeBrVKWrffg0Wjy8f3gnxfI8VDGj1H /KA51TvjOv/lQTh+uq+3OWvd4QGERPeXYJwK+1RQPCBhl1gKA0zGGcVIs/U8rBe2oHQI HKkFumy2cwL5PhJSsxKYLeqP3X1bb2/QZPaJkmN4amTYtMMZ+gybIhrJpUmGtRMJBAZI VmNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=SwLw5MBCG02Jl++a6Q2awKENwLIvb/nVIfIi7Epioyc=; b=0VQPLpIOY5AEj75fRlnTqlRcTfNZQCytH0Jzf1L7Yfqd5c+cODuQUCRKfU8JkPygnQ KnK3lN9nv3FOwKh5lavTOYOlPjG1xHKgv/yNUMrFHo5PT1kkUyEqebIivlV0N3usWdkW fgFO3dxo82i0xcypfh5F43HjnNp6kCJAqwtCZJ4diYTJWlniPLmny5zWYZTSgWWyqt+J wuwRSmo/ZahaisBaDHBk1xhsS5KAJ9EwnRbY85m8Kzc7EzCt5qIb9mWHDTBpe7scW5ol 5y102rUNQ0nUiocN2yvq1HzQy6nLgIyszSpYkFIFUA6xNn4l6WXUiJGCygf6FyXthSbT 5NHA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u8-v6si697405plh.22.2018.04.18.00.21.15; Wed, 18 Apr 2018 00:21:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753048AbeDRHUF (ORCPT + 99 others); Wed, 18 Apr 2018 03:20:05 -0400 Received: from mx2.suse.de ([195.135.220.15]:36702 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752665AbeDRHUE (ORCPT ); Wed, 18 Apr 2018 03:20:04 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 2FEBAAD44; Wed, 18 Apr 2018 07:20:03 +0000 (UTC) Date: Wed, 18 Apr 2018 09:20:02 +0200 From: Michal Hocko To: Minchan Kim Cc: Andrew Morton , LKML , linux-mm , Johannes Weiner , Vladimir Davydov Subject: Re: [PATCH] mm:memcg: add __GFP_NOWARN in __memcg_schedule_kmem_cache_create Message-ID: <20180418072002.GN17484@dhcp22.suse.cz> References: <20180418022912.248417-1-minchan@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180418022912.248417-1-minchan@kernel.org> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 18-04-18 11:29:12, Minchan Kim wrote: > If there are heavy memory pressure, page allocation with __GFP_NOWAIT > fails easily although it's order-0 request. > I got below warning 9 times for normal boot. > > [ 17.072747] c0 0 : page allocation failure: order:0, mode:0x2200000(GFP_NOWAIT|__GFP_NOTRACK) > < snip > > [ 17.072789] c0 0 Call trace: > [ 17.072803] c0 0 [] dump_backtrace+0x0/0x4 > [ 17.072813] c0 0 [] dump_stack+0xa4/0xc0 > [ 17.072822] c0 0 [] warn_alloc+0xd4/0x15c > [ 17.072829] c0 0 [] __alloc_pages_nodemask+0xf88/0x10fc > [ 17.072838] c0 0 [] alloc_slab_page+0x40/0x18c > [ 17.072843] c0 0 [] new_slab+0x2b8/0x2e0 > [ 17.072849] c0 0 [] ___slab_alloc+0x25c/0x464 > [ 17.072858] c0 0 [] __kmalloc+0x394/0x498 > [ 17.072865] c0 0 [] memcg_kmem_get_cache+0x114/0x2b8 > [ 17.072870] c0 0 [] kmem_cache_alloc+0x98/0x3e8 > [ 17.072878] c0 0 [] mmap_region+0x3bc/0x8c0 > [ 17.072884] c0 0 [] do_mmap+0x40c/0x43c > [ 17.072890] c0 0 [] vm_mmap_pgoff+0x15c/0x1e4 > [ 17.072898] c0 0 [] sys_mmap+0xb0/0xc8 > [ 17.072904] c0 0 [] el0_svc_naked+0x24/0x28 > [ 17.072908] c0 0 Mem-Info: > [ 17.072920] c0 0 active_anon:17124 inactive_anon:193 isolated_anon:0 > [ 17.072920] c0 0 active_file:7898 inactive_file:712955 isolated_file:55 > [ 17.072920] c0 0 unevictable:0 dirty:27 writeback:18 unstable:0 > [ 17.072920] c0 0 slab_reclaimable:12250 slab_unreclaimable:23334 > [ 17.072920] c0 0 mapped:19310 shmem:212 pagetables:816 bounce:0 > [ 17.072920] c0 0 free:36561 free_pcp:1205 free_cma:35615 > [ 17.072933] c0 0 Node 0 active_anon:68496kB inactive_anon:772kB active_file:31592kB inactive_file:2851820kB unevictable:0kB isolated(anon):0kB isolated(file):220kB mapped:77240kB dirty:108kB writeback:72kB shmem:848kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no > [ 17.072945] c0 0 DMA free:142188kB min:3056kB low:3820kB high:4584kB active_anon:10052kB inactive_anon:12kB active_file:312kB inactive_file:1412620kB unevictable:0kB writepending:0kB present:1781412kB managed:1604728kB mlocked:0kB slab_reclaimable:3592kB slab_unreclaimable:876kB kernel_stack:400kB pagetables:52kB bounce:0kB free_pcp:1436kB local_pcp:124kB free_cma:142492kB > [ 17.072949] c0 0 lowmem_reserve[]: 0 1842 1842 > [ 17.072966] c0 0 Normal free:4056kB min:4172kB low:5212kB high:6252kB active_anon:58376kB inactive_anon:760kB active_file:31348kB inactive_file:1439040kB unevictable:0kB writepending:180kB present:2000636kB managed:1923688kB mlocked:0kB slab_reclaimable:45408kB slab_unreclaimable:92460kB kernel_stack:9680kB pagetables:3212kB bounce:0kB free_pcp:3392kB local_pcp:688kB free_cma:0kB > [ 17.072971] c0 0 lowmem_reserve[]: 0 0 0 > [ 17.072982] c0 0 DMA: 0*4kB 0*8kB 1*16kB (C) 0*32kB 0*64kB 0*128kB 1*256kB (C) 1*512kB (C) 0*1024kB 1*2048kB (C) 34*4096kB (C) = 142096kB > [ 17.073024] c0 0 Normal: 228*4kB (UMEH) 172*8kB (UMH) 23*16kB (UH) 24*32kB (H) 5*64kB (H) 1*128kB (H) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3872kB > [ 17.073069] c0 0 721350 total pagecache pages > [ 17.073073] c0 0 0 pages in swap cache > [ 17.073078] c0 0 Swap cache stats: add 0, delete 0, find 0/0 > [ 17.073081] c0 0 Free swap = 0kB > [ 17.073085] c0 0 Total swap = 0kB > [ 17.073089] c0 0 945512 pages RAM > [ 17.073093] c0 0 0 pages HighMem/MovableOnly > [ 17.073097] c0 0 63408 pages reserved > [ 17.073100] c0 0 51200 pages cma reserved > > Let's not make user scared. This is not a proper explanation. So what exactly happens when this allocation fails? I would suggest something like the following " __memcg_schedule_kmem_cache_create tries to create a shadow slab cache and the worker allocation failure is not really critical because we will retry on the next kmem charge. We might miss some charges but that shouldn't be critical. The excessive allocation failure report is not very much helpful. Replace it with a rate limited single line output so that we know that there is a lot of these failures and that we need to do something about it in future. " With the last part to be implemented of course. > Cc: Johannes Weiner > Cc: Michal Hocko > Cc: Vladimir Davydov > Signed-off-by: Minchan Kim > --- > mm/memcontrol.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index 448db08d97a0..671d07e73a3b 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -2200,7 +2200,7 @@ static void __memcg_schedule_kmem_cache_create(struct mem_cgroup *memcg, > { > struct memcg_kmem_cache_create_work *cw; > > - cw = kmalloc(sizeof(*cw), GFP_NOWAIT); > + cw = kmalloc(sizeof(*cw), GFP_NOWAIT | __GFP_NOWARN); > if (!cw) > return; > > -- > 2.17.0.484.g0c8726318c-goog -- Michal Hocko SUSE Labs