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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 7AB1AC54FD0 for ; Mon, 27 Apr 2020 08:20:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 217D620661 for ; Mon, 27 Apr 2020 08:20:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 217D620661 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=sony.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6AEED8E0005; Mon, 27 Apr 2020 04:20:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 660228E0001; Mon, 27 Apr 2020 04:20:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 54EA28E0005; Mon, 27 Apr 2020 04:20:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0172.hostedemail.com [216.40.44.172]) by kanga.kvack.org (Postfix) with ESMTP id 3B3AE8E0001 for ; Mon, 27 Apr 2020 04:20:36 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id D7646180AD804 for ; Mon, 27 Apr 2020 08:20:35 +0000 (UTC) X-FDA: 76752938430.30.shop07_5c762f86dbb3b X-HE-Tag: shop07_5c762f86dbb3b X-Filterd-Recvd-Size: 4938 Received: from SELDSEGREL01.sonyericsson.com (seldsegrel01.sonyericsson.com [37.139.156.29]) by imf28.hostedemail.com (Postfix) with ESMTP for ; Mon, 27 Apr 2020 08:20:35 +0000 (UTC) Subject: Re: [patch] mm, oom: stop reclaiming if GFP_ATOMIC will start failing soon To: Andrew Morton , David Rientjes CC: Vlastimil Babka , , References: <20200425172706.26b5011293e8dc77b1dccaf3@linux-foundation.org> From: peter enderborg Message-ID: <7726e8a8-8390-cee8-3480-4e68bf26f08a@sony.com> Date: Mon, 27 Apr 2020 10:20:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200425172706.26b5011293e8dc77b1dccaf3@linux-foundation.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Language: en-GB X-SEG-SpamProfiler-Analysis: v=2.3 cv=Nc2YKFL4 c=1 sm=1 tr=0 a=kIrCkORFHx6JeP9rmF/Kww==:117 a=IkcTkHD0fZMA:10 a=cl8xLZFz6L8A:10 a=1XWaLZrsAAAA:8 a=_KWB5BKwUhRobCCBmOoA:9 a=QEXdDO2ut3YA:10 X-SEG-SpamProfiler-Score: 0 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 4/26/20 2:27 AM, Andrew Morton wrote: > On Fri, 24 Apr 2020 13:48:06 -0700 (PDT) David Rientjes wrote: > >> If GFP_ATOMIC allocations will start failing soon because the amount of >> free memory is substantially under per-zone min watermarks, it is better >> to oom kill a process rather than continue to reclaim. >> >> This intends to significantly reduce the number of page allocation >> failures that are encountered when the demands of user and atomic >> allocations overwhelm the ability of reclaim to keep up. We can see thi= s >> with a high ingress of networking traffic where memory allocated in irq >> context can overwhelm the ability to reclaim fast enough such that user >> memory consistently loops. In that case, we have reclaimable memory, an= d > "user memory allocation", I assume? Or maybe "blockable memory > allocatoins". > >> reclaiming is successful, but we've fully depleted memory reserves that >> are allowed for non-blockable allocations. >> >> Commit 400e22499dd9 ("mm: don't warn about allocations which stall for >> too long") removed evidence of user allocations stalling because of this= , >> but the situation can apply anytime we get "page allocation failures" >> where reclaim is happening but per-zone min watermarks are starved: >> >> Node 0 Normal free:87356kB min:221984kB low:416984kB high:611984kB activ= e_anon:123009936kB inactive_anon:67647652kB active_file:429612kB inactive_f= ile:209980kB unevictable:112348kB writepending:260kB present:198180864kB ma= naged:195027624kB mlocked:81756kB kernel_stack:24040kB pagetables:11460kB b= ounce:0kB free_pcp:940kB local_pcp:96kB free_cma:0kB >> lowmem_reserve[]: 0 0 0 0 >> Node 1 Normal free:105616kB min:225568kB low:423716kB high:621864kB acti= ve_anon:122124196kB inactive_anon:74112696kB active_file:39172kB inactive_f= ile:103696kB unevictable:204480kB writepending:180kB present:201326592kB ma= naged:198174372kB mlocked:204480kB kernel_stack:11328kB pagetables:3680kB b= ounce:0kB free_pcp:1140kB local_pcp:0kB free_cma:0kB >> lowmem_reserve[]: 0 0 0 0 >> >> Without this patch, there is no guarantee that user memory allocations >> will ever be successful when non-blockable allocations overwhelm the >> ability to get above per-zone min watermarks. >> >> This doesn't solve page allocation failures entirely since it's a >> preemptive measure based on watermarks that requires concurrent blockabl= e >> allocations to trigger the oom kill. To complete solve page allocation >> failures, it would be possible to do the same watermark check for non- >> blockable allocations and then queue a worker to asynchronously oom kill >> if it finds watermarks to be sufficiently low as well. >> > Well, what's really going on here? > > Is networking potentially consuming an unbounded amount of memory? If > so, then killing a process will just cause networking to consume more > memory then hit against the same thing. So presumably the answer is > "no, the watermarks are inappropriately set for this workload". > > So would it not be sensible to dynamically adjust the watermarks in > response to this condition? Maintain a larger pool of memory for these > allocations? Or possibly push back on networking and tell it to reduce > its queue sizes? So that stuff doesn't keep on getting oom-killed? > I think I seen similar issues when dma-buf allocate a lot.=C2=A0 But that i= s on older kernels and out of tree. So networking is maybe not the only cause. dma-buf are used a lot for camer= a stuff in android.