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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A87EFC433EF for ; Mon, 25 Oct 2021 08:04:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4E8BD60F46 for ; Mon, 25 Oct 2021 08:04:08 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4E8BD60F46 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id D8772940007; Mon, 25 Oct 2021 04:04:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D36CC6B0072; Mon, 25 Oct 2021 04:04:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BFE85940007; Mon, 25 Oct 2021 04:04:07 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0126.hostedemail.com [216.40.44.126]) by kanga.kvack.org (Postfix) with ESMTP id AD7B46B006C for ; Mon, 25 Oct 2021 04:04:07 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 67D4218026592 for ; Mon, 25 Oct 2021 08:04:07 +0000 (UTC) X-FDA: 78734221734.28.DD6C856 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf26.hostedemail.com (Postfix) with ESMTP id D81D320019D6 for ; Mon, 25 Oct 2021 08:04:07 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id AC29C1FD34; Mon, 25 Oct 2021 08:04:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1635149045; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=l21SlX/9kh43Ic37AW53KRYg/QWXqmopDdPfmAH/kdc=; b=eMrOCgSaFdI3lzR7WkVsSne/0Whu14mXXOGHTE5EXC7LHFchVV5T3UBKFzMCbaDaY613w1 ikdq4RNXE7zyGDMnT3jKdP2gKvt6jH33g8ZZPjWfjj8njf3MaNH5I51wDnqQYTCASz7FRd r6Jz1WJWiRfnNmBh7Dku+xmZFCp0kl0= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 09D93A3B81; Mon, 25 Oct 2021 08:04:04 +0000 (UTC) Date: Mon, 25 Oct 2021 10:04:04 +0200 From: Michal Hocko To: Tetsuo Handa Cc: Vasily Averin , Roman Gushchin , Uladzislau Rezki , Vlastimil Babka , Shakeel Butt , Mel Gorman , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel@openvz.org, Johannes Weiner , Vladimir Davydov , Andrew Morton Subject: Re: [PATCH memcg v3 2/3] mm, oom: do not trigger out_of_memory from the #PF Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 8roqerdqh7acdwpm3944bgyexysc381r Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=eMrOCgSa; spf=pass (imf26.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D81D320019D6 X-HE-Tag: 1635149047-186250 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 Sun 24-10-21 00:01:07, Tetsuo Handa wrote: > On 2021/10/23 22:20, Vasily Averin wrote: > > /* > > - * The pagefault handler calls here because it is out of memory, so kill a > > - * memory-hogging task. If oom_lock is held by somebody else, a parallel oom > > - * killing is already in progress so do nothing. > > + * The pagefault handler calls here because some allocation has failed. We have > > + * to take care of the memcg OOM here because this is the only safe context without > > + * any locks held but let the oom killer triggered from the allocation context care > > + * about the global OOM. > > */ > > Excuse me for a stupid question. I consider > > if (!mutex_trylock(&oom_lock)) > return; > out_of_memory(&oc); > mutex_unlock(&oom_lock); > > here as the last resort (safeguard) when neither __alloc_pages_may_oom() > nor mem_cgroup_out_of_memory() can make progress. This patch says > > let the oom killer triggered from the allocation context care > about the global OOM. > > but what if the OOM killer cannot be invoked from the allocation context? > Is there a guarantee that all memory allocations which might result in > VM_FAULT_OOM can invoke the OOM killer? I do not think there is any guarantee. This code has meant to be a safeguard but it turns out to be adding more harm than a safety. There are several scenarios mentioned in this thread where this would be counter productive or outright wrong thing to do. On the other hand it is hard to imagine any legitimate situation where this would be a right thing to do. Maybe you have something more specific in mind? What would be the legit code to rely on OOM handling out of the line (where the details about the allocation scope is lost)? -- Michal Hocko SUSE Labs