From patchwork Tue Mar 10 21:39:48 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Rientjes X-Patchwork-Id: 11430303 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 1493F138D for ; Tue, 10 Mar 2020 21:39:53 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D4E6D22522 for ; Tue, 10 Mar 2020 21:39:52 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="B4tbgodb" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D4E6D22522 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 100816B0006; Tue, 10 Mar 2020 17:39:52 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 089656B0007; Tue, 10 Mar 2020 17:39:52 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E6B5D6B0008; Tue, 10 Mar 2020 17:39:51 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id CBAB26B0006 for ; Tue, 10 Mar 2020 17:39:51 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 7B89F8248047 for ; Tue, 10 Mar 2020 21:39:51 +0000 (UTC) X-FDA: 76580770182.08.bears48_38ea2b4fd204d X-Spam-Summary: 2,0,0,1ec18537223e59e5,d41d8cd98f00b204,rientjes@google.com,,RULES_HIT:41:355:379:800:960:966:973:988:989:1260:1277:1313:1314:1345:1437:1516:1518:1534:1541:1593:1594:1711:1730:1747:1777:1792:2196:2198:2199:2200:2393:2559:2562:3138:3139:3140:3141:3142:3152:3352:3865:3866:3867:3868:3870:3871:3874:4250:4385:5007:6261:6653:8660:9038:10004:10400:10450:10455:11026:11473:11658:11914:12043:12296:12297:12438:12517:12519:12555:12679:12895:13069:13148:13161:13229:13230:13311:13357:13439:13870:14096:14097:14181:14659:14721:19904:19999:21063:21080:21324:21444:21451:21627:21966:30054:30056,0,RBL:209.85.215.196:@google.com:.lbl8.mailshell.net-66.100.201.100 62.18.0.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:24,LUA_SUMMARY:none X-HE-Tag: bears48_38ea2b4fd204d X-Filterd-Recvd-Size: 4626 Received: from mail-pg1-f196.google.com (mail-pg1-f196.google.com [209.85.215.196]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Tue, 10 Mar 2020 21:39:51 +0000 (UTC) Received: by mail-pg1-f196.google.com with SMTP id y30so6894084pga.13 for ; Tue, 10 Mar 2020 14:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:user-agent:mime-version; bh=vzwzOrISC8AE6Ft8LM/EkNEsA5EmXRG9n4oBptOAC84=; b=B4tbgodbmpEw4if6P+g89G1vo8NtdE1LRRFqpf4jl226jISTdzX3Svw0VVSLA8/+Yg 96cjfZK1I4vhnM3JeLPXB2NI3BtHwOeLYDHQbUmHnxTpr7mzT+95ABi/GxT+ZmxZBeLj AUeNP7/DQI0guHcsT+BsZhVY9jHenjA83RyswSovB48KEssZCLYOSKWj2qRSPj48Nacl 20WfGk9h2ZhBNGF46yFx41faRs5sJYvjhncO3iWFkT6CEDMvHSbs4+tf24mPECaLHe0d EUKR1BUR9PIQOobfSAjqPIDG5pAvv5b1LCEsBvQ+oR9V52FJHWBZa6wWOvwwW+jT4UoP N0Mg== 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:message-id:user-agent :mime-version; bh=vzwzOrISC8AE6Ft8LM/EkNEsA5EmXRG9n4oBptOAC84=; b=o3GStUVFjwXkLmeG0IimjyqO1ZJZyE5RpAk5rVQ7s+v+dopZ6Jqz+noGomYUGV4/+O 5opa72h5kmFarV7hk/tL/nZplQIenTYsdYimROk8an4McJ0XD73GxahShWC57/vqdjHh OP2ALx8hHRs1ZCJOe9ZvVRlZkBY3Jq9rt12WxIbKg+0pzLJnNa1JfdPlHxNiaREIx3g/ lyDLvt41FTDihlopNCOfydTR+q661G1k+mtJi16ZA6u3+b6aOuH3HMTt8uaBbrZuEClU 9+RAFOheZ5KAnMiXOW939YDECWUdrO7EF0xEZYBGeHbQI1zdbkMR4zEQcHBGJvNXlWzV jsAQ== X-Gm-Message-State: ANhLgQ3pFMW8OYFHBRm4kEYGSGTswOxwc2kt/40bqM+Lc8LtOt0D9Qu3 VYZwHUkoF7aUOmUNNVEGkUYicA== X-Google-Smtp-Source: ADFU+vuI2NxooomqK+7EhwkWpuecOjCyFtdWZeLBT5Dysz/5KuClAiEyVeMPqCHMFXTtTucpEYxUSQ== X-Received: by 2002:a65:5b49:: with SMTP id y9mr22608048pgr.153.1583876389690; Tue, 10 Mar 2020 14:39:49 -0700 (PDT) Received: from [2620:15c:17:3:3a5:23a7:5e32:4598] ([2620:15c:17:3:3a5:23a7:5e32:4598]) by smtp.gmail.com with ESMTPSA id m26sm2252920pgc.77.2020.03.10.14.39.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Mar 2020 14:39:49 -0700 (PDT) Date: Tue, 10 Mar 2020 14:39:48 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Andrew Morton cc: Vlastimil Babka , Michal Hocko , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [patch] mm, oom: prevent soft lockup on memcg oom for UP systems Message-ID: User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.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: When a process is oom killed as a result of memcg limits and the victim is waiting to exit, nothing ends up actually yielding the processor back to the victim on UP systems with preemption disabled. Instead, the charging process simply loops in memcg reclaim and eventually soft lockups. Memory cgroup out of memory: Killed process 808 (repro) total-vm:41944kB, anon-rss:35344kB, file-rss:504kB, shmem-rss:0kB, UID:0 pgtables:108kB oom_score_adj:0 watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [repro:806] CPU: 0 PID: 806 Comm: repro Not tainted 5.6.0-rc5+ #136 RIP: 0010:shrink_lruvec+0x4e9/0xa40 ... Call Trace: shrink_node+0x40d/0x7d0 do_try_to_free_pages+0x13f/0x470 try_to_free_mem_cgroup_pages+0x16d/0x230 try_charge+0x247/0xac0 mem_cgroup_try_charge+0x10a/0x220 mem_cgroup_try_charge_delay+0x1e/0x40 handle_mm_fault+0xdf2/0x15f0 do_user_addr_fault+0x21f/0x420 page_fault+0x2f/0x40 Make sure that something ends up actually yielding the processor back to the victim to allow for memory freeing. Most appropriate place appears to be shrink_node_memcgs() where the iteration of all decendant memcgs could be particularly lengthy. Cc: Vlastimil Babka Cc: Michal Hocko Cc: stable@vger.kernel.org Signed-off-by: David Rientjes --- mm/vmscan.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/vmscan.c b/mm/vmscan.c --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -2637,6 +2637,8 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc) unsigned long reclaimed; unsigned long scanned; + cond_resched(); + switch (mem_cgroup_protected(target_memcg, memcg)) { case MEMCG_PROT_MIN: /*