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=-12.9 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1, USER_IN_DEF_DKIM_WL autolearn=ham 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 93637C0044D for ; Wed, 11 Mar 2020 19:38:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 72EF720737 for ; Wed, 11 Mar 2020 19:38:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="gEjOycvx" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 72EF720737 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 C66226B0005; Wed, 11 Mar 2020 15:38:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BF0916B0006; Wed, 11 Mar 2020 15:38:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB9036B0007; Wed, 11 Mar 2020 15:38:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0174.hostedemail.com [216.40.44.174]) by kanga.kvack.org (Postfix) with ESMTP id 8FF256B0005 for ; Wed, 11 Mar 2020 15:38:11 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 416E0812D for ; Wed, 11 Mar 2020 19:38:11 +0000 (UTC) X-FDA: 76584092382.01.man51_477058a50d452 X-HE-Tag: man51_477058a50d452 X-Filterd-Recvd-Size: 4860 Received: from mail-pg1-f193.google.com (mail-pg1-f193.google.com [209.85.215.193]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Wed, 11 Mar 2020 19:38:10 +0000 (UTC) Received: by mail-pg1-f193.google.com with SMTP id y30so1724663pga.13 for ; Wed, 11 Mar 2020 12:38:10 -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=Zb5q/Mu4Y05A8mwi2SFVQb8nWna0MTPdNN6cb7H8VpE=; b=gEjOycvx4YQW2uEn6K7qwHEwfNAGZYNaSKbDvy1IVY56seaG5DAmfh9kBhmrYGMXqs ZqlKVr1XsUWCWptcndhsmwO+Mtiq+tcdxEPjddRld13v5IEbCsKSLYc3mqVr/LB9UbYs zboqVnO8hTlArH7Wi/Z0HcqJP/jrr5og7GZYWIP5h64jIuXT5+E+j66XWTvNUP1/kiLD OC/jyASsnhZOhK4+g4oHDSRhZYjk9f7n9t1ZTyLlA1Og3ObGHHgXxcfjPOPJo1pyeX4K NJzwpMsOguK2wm7Z1Xgr8sqdJSnMYtAK3lVEKy3JGL3JELhaYj4cihBUmV6I1EWIAUcP sNsg== 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=Zb5q/Mu4Y05A8mwi2SFVQb8nWna0MTPdNN6cb7H8VpE=; b=gtRbNOd4rmgjWdcQWMUyaiASK0mFm1oryOZC2GOrxxCGsh5Mvfe2v7sr3aSS+JBcA2 A5lFXMLe5OphKmNJiWwdfLLvP85ABH4qH1HdPw9a42kjPFgvqIO+YqbYTnr7pHBLhwES 9RSSWhZKGd25Te8YMcVKu3FWD8CBJAx3IQLMJykmBi4dLby0rQs/5B3uP7qoWi9BwmIM 5ggzEKozkzvugSTfLwsZeifQlVuVDgvMfF3OpCvEezhM+FLOhVFmMWHKYAiKlLuDujQD ka+XpAWCk11AaaaWL5CxoKJOdWY533zXA/wkeKMVzDDWT6OAWRDPEy8j8Aye22hBgI49 j3lA== X-Gm-Message-State: ANhLgQ0omVgG7OUIxwXZSHw8eaoBcyggzSF9roJYqxNTT1iMXHWOHJ7O 3jC/OP+KmNkpWVvfq10lYTk9uw== X-Google-Smtp-Source: ADFU+vu4w2Fjd9qLpxvfjtML0AhQNSJS4jd+sFLDO6cpsSiLPD5qfQgTvXBo2xt9ibO4JgPeFVVIxg== X-Received: by 2002:a62:5cc1:: with SMTP id q184mr2272743pfb.259.1583955489598; Wed, 11 Mar 2020 12:38:09 -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 x72sm13897760pfc.156.2020.03.11.12.38.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Mar 2020 12:38:08 -0700 (PDT) Date: Wed, 11 Mar 2020 12:38:07 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Tetsuo Handa cc: Andrew Morton , Vlastimil Babka , Michal Hocko , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [patch] mm, oom: prevent soft lockup on memcg oom for UP systems In-Reply-To: <7a6170fc-b247-e327-321a-b99fb53f552d@i-love.sakura.ne.jp> Message-ID: References: <0e5ca6ee-d460-db8e-aba2-79aa7a66fad1@I-love.SAKURA.ne.jp> <7a6170fc-b247-e327-321a-b99fb53f552d@i-love.sakura.ne.jp> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Wed, 11 Mar 2020, Tetsuo Handa wrote: > >>> 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(); > >>> + > >> > >> Is this safe for CONFIG_PREEMPTION case? If current thread has realtime priority, > >> can we guarantee that the OOM victim (well, the OOM reaper kernel thread rather > >> than the OOM victim ?) gets scheduled? > >> > > > > I think it's the best we can do that immediately solves the issue unless > > you have another idea in mind? > > "schedule_timeout_killable(1) outside of oom_lock" or "the OOM reaper grabs oom_lock > so that allocating threads guarantee that the OOM reaper gets scheduled" or "direct OOM > reaping so that allocating threads guarantee that some memory is reclaimed". > The cond_resched() here is needed if the iteration is lengthy depending on the number of descendant memcgs already. schedule_timeout_killable(1) does not make any guarantees that current will be scheduled after the victim or oom_reaper on UP systems. If you have an alternate patch to try, we can test it. But since this cond_resched() is needed anyway, I'm not sure it will change the result. > > > >>> switch (mem_cgroup_protected(target_memcg, memcg)) { > >>> case MEMCG_PROT_MIN: > >>> /* > >>> > >> > >