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 1BB1BC10DCE for ; Fri, 13 Mar 2020 22:01:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C2A982074A for ; Fri, 13 Mar 2020 22:01:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="o6zQrGkf" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C2A982074A 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 732BE6B0006; Fri, 13 Mar 2020 18:01:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6E3D46B0007; Fri, 13 Mar 2020 18:01:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5D1E66B0008; Fri, 13 Mar 2020 18:01:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0103.hostedemail.com [216.40.44.103]) by kanga.kvack.org (Postfix) with ESMTP id 42D116B0006 for ; Fri, 13 Mar 2020 18:01:19 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id D61594DD7 for ; Fri, 13 Mar 2020 22:01:18 +0000 (UTC) X-FDA: 76591710636.14.home46_7fd9020313932 X-HE-Tag: home46_7fd9020313932 X-Filterd-Recvd-Size: 6253 Received: from mail-pg1-f196.google.com (mail-pg1-f196.google.com [209.85.215.196]) by imf33.hostedemail.com (Postfix) with ESMTP for ; Fri, 13 Mar 2020 22:01:18 +0000 (UTC) Received: by mail-pg1-f196.google.com with SMTP id a32so4914453pga.4 for ; Fri, 13 Mar 2020 15:01:18 -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=UFE9bZCG4sWGzF0InHa1jECdp69Y2rcipLo/idzivo8=; b=o6zQrGkfIrtt5FoOA5+Q0j4dDaC/p7dfapsUM9vxhhM+DfktEGLaFpmG+oJu7R2wsa /ERomm2bMVyt5ZDEjmCApn34tTXPJQ7eL1gY0xIl5qobH2D22pkddabiBGWAIrW9fxEK r/KErvHJfEzlAvSdcCbPAlENTb7rhpHa6+qK2KP980KgDmZH5wTO3qEw7uiocAHiSqGT eRERMZ8rirAGZmQN3OtCje2+L/Wcg7rBc4PpBWK9ziK7nT4VGQlLAAxontaTVAWvv3VI oF+L+fwq6A2V0o/HjtLHDGpu4RccNKhjSRtfT1//gJRJKJBfUu8U0NsPd9qqMpIY2xhf UA4g== 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=UFE9bZCG4sWGzF0InHa1jECdp69Y2rcipLo/idzivo8=; b=srnZBrdH8t+pPAEYg2AAncRVvV4PnpTcouclRunymcQrTKFHtgSYz5o4tJnIhAuciW 4GwZjQ5MfhDxtnz/SFmqXRs8st/x08CbHDsdJFCv1uXJoibY/gz+84sQbJ0Ypva1SrM7 0cxMYmismtyOSU6lfysbMGJel6yUH5F6pEanGKWOeafXqXyy7NtM1taXKESUIXE+ke+k QAUzeCMHKPZAoMZmMR5daInDUdT3bRPsUzCsTIZrLMvY2ZA0+NQpH4qknGnyoouDSpdU kfy5fm2V0+f05s1K+Ixqc8sYXyruzGQisKvTNn14+xzFg82gMOMqdE5lcTWxRyEVV+kS CCLg== X-Gm-Message-State: ANhLgQ2wfdAq5Th7DRlj1QypxGHEDNLH5tOlLRLhkY4MD6iK53kwBccy 992WLSW3sxWGwT/9oSRWwzJ8HA== X-Google-Smtp-Source: ADFU+vvtFE1n8c5EAfrwRlVwAOQFqHnZX9L7K9vdbWqUnmLqRbdFciiAuv6RUYbMOQFh1awwltDZfA== X-Received: by 2002:a63:e50b:: with SMTP id r11mr6530266pgh.178.1584136877223; Fri, 13 Mar 2020 15:01:17 -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 d6sm8199581pfn.214.2020.03.13.15.01.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Mar 2020 15:01:16 -0700 (PDT) Date: Fri, 13 Mar 2020 15:01:15 -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: <202003130015.02D0F9uT079462@www262.sakura.ne.jp> Message-ID: References: <202003120012.02C0CEUB043533@www262.sakura.ne.jp> <202003130015.02D0F9uT079462@www262.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 Fri, 13 Mar 2020, Tetsuo Handa wrote: > > On an UP kernel with swap disabled, you limit a memcg to 100MB and start > > three processes that each fault 40MB attached to it. Same reproducer as > > the "mm, oom: make a last minute check to prevent unnecessary memcg oom > > kills" patch except in that case there are two cores. > > > > I'm not a heavy memcg user. Please provide steps for reproducing your problem > in a "copy and pastable" way (e.g. bash script, C program). > Use Documentation/admin-guide/cgroup-v1/memory.rst or Documentation/admin-guide/cgroup-v2.rst to setup a memcg depending on which cgroup version you use, limit it to 100MB, and attach your process to it. Run three programs that fault 40MB. To do that, you need to use mmap: (void)mmap(NULL, 40 << 20, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_POPULATE, 0, 0); Have it stall after populating the memory: for (;;); > > > @@ -1576,6 +1576,7 @@ static bool mem_cgroup_out_of_memory(struct mem_cgroup *memcg, gfp_t gfp_mask, > > > */ > > > ret = should_force_charge() || out_of_memory(&oc); > > > mutex_unlock(&oom_lock); > > > + schedule_timeout_killable(1); > > > return ret; > > > } > > > > > > > If current was process chosen for oom kill, this would actually induce the > > problem, not fix it. > > > > Why? Memcg OOM path allows using forced charge path if should_force_charge() == true. > > Since your lockup report > > 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 > > says that allocating thread was calling try_to_free_mem_cgroup_pages() from try_charge(), > allocating thread must be able to reach mem_cgroup_out_of_memory() from mem_cgroup_oom() > from try_charge(). And actually > > 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 > > says that allocating thread did reach mem_cgroup_out_of_memory(). Then, allocating thread > must be able to sleep at mem_cgroup_out_of_memory() if schedule_timeout_killable(1) is > mem_cgroup_out_of_memory(). > > Also, if current process was chosen for OOM-kill, current process will be able to leave > try_charge() due to should_force_charge() == true, won't it? > > Thus, how can "this would actually induce the problem, not fix it." happen? The entire issue is that the victim never gets a chance to run because the allocator doesn't give it a chance to run on an UP system. Your patch is broken because if the victim is current, you've lost your golden opportunity to actually exit and ceded control to the allocator that will now starve the victim.