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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45643C433EF for ; Fri, 8 Apr 2022 10:51:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A5C2A6B0074; Fri, 8 Apr 2022 06:51:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A0B9C8D0001; Fri, 8 Apr 2022 06:51:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8D30B6B0078; Fri, 8 Apr 2022 06:51:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 7E30D6B0074 for ; Fri, 8 Apr 2022 06:51:44 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 56A1D25A60 for ; Fri, 8 Apr 2022 10:51:44 +0000 (UTC) X-FDA: 79333396128.05.6BBD2E9 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf19.hostedemail.com (Postfix) with ESMTP id 9EFFE1A0009 for ; Fri, 8 Apr 2022 10:51:43 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 2B27E215FE; Fri, 8 Apr 2022 10:51:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1649415102; 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=1a4jrx9mGC0EPdMRiBGre9n2QoqPCsrsdgfrk9qPbm0=; b=Rlo/ziEzBdMonfHmyajFMaMOJTzujnRsIbSDaf50ESpDKUiAQwv/5Wd4tHgt8YjQkRLLzi 7rO47CI13uYM2vfDRO1676swOPusldjr81f91RAjA+1A73ELcPtTDUMQZor9L5dVcVaIv0 fDqe3EJ8SdpyGv5I0ocKKyTm1m0o/5E= 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 BA0E4A3B82; Fri, 8 Apr 2022 10:51:41 +0000 (UTC) Date: Fri, 8 Apr 2022 12:51:41 +0200 From: Michal Hocko To: Nico Pache Cc: Thomas Gleixner , Peter Zijlstra , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Rafael Aquini , Waiman Long , Baoquan He , Christoph von Recklinghausen , Don Dutile , "Herton R . Krzesinski" , David Rientjes , Andrea Arcangeli , Andrew Morton , Davidlohr Bueso , Ingo Molnar , Joel Savitz , Darren Hart , stable@kernel.org Subject: Re: [PATCH v8] oom_kill.c: futex: Don't OOM reap the VMA containing the robust_list_head Message-ID: References: <20220408032809.3696798-1-npache@redhat.com> <20220408081549.GM2731@worktop.programming.kicks-ass.net> <87tub4j7hg.ffs@tglx> <676fb197-d045-c537-c1f7-e18320a6d15f@redhat.com> <2293c547-3878-435a-ec1c-854c3181ad14@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2293c547-3878-435a-ec1c-854c3181ad14@redhat.com> X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: i8sdqgawjwa9q57q87dzmn1x83x3qbfy Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="Rlo/ziEz"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf19.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Rspamd-Queue-Id: 9EFFE1A0009 X-HE-Tag: 1649415103-115980 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 08-04-22 06:36:40, Nico Pache wrote: > > > On 4/8/22 05:59, Michal Hocko wrote: > > On Fri 08-04-22 05:40:09, Nico Pache wrote: > >> > >> > >> On 4/8/22 05:36, Michal Hocko wrote: > >>> On Fri 08-04-22 04:52:33, Nico Pache wrote: > >>> [...] > >>>> In a heavily contended CPU with high memory pressure the delay may also > >>>> lead to other processes unnecessarily OOMing. > >>> > >>> Let me just comment on this part because there is likely a confusion > >>> inlved. Delaying the oom_reaper _cannot_ lead to additional OOM killing > >>> because the the oom killing is throttled by existence of a preexisting > >>> OOM victim. In other words as long as there is an alive victim no > >>> further victims are not selected and the oom killer backs off. The > >>> oom_repaer will hide the alive oom victim after it is processed. > >>> The longer the delay will be the longer an oom victim can block a > >>> further progress but it cannot really cause unnecessary OOMing. > >> Is it not the case that if we delay an OOM, the amount of available memory stays > >> limited and other processes that are allocating memory can become OOM candidates? > > > > No. Have a look at oom_evaluate_task (tsk_is_oom_victim check). > Ok I see. > > Doesnt the delay then allow the system to run into the following case more easily?: > pr_warn("Out of memory and no killable processes...\n"); > panic("System is deadlocked on memory\n"); No. Aborting the oom victim search (above mentioned) will cause out_of_memory to bail out and return to the page allocator. As I've said the only problem with delaying the oom_reaper is that _iff_ the oom victim cannot terminate (because it is stuck somewhere in the kernel) on its own then the oom situation (be it global, cpuset or memcg) will take longer so allocating tasks will not be able to make a forward progress. -- Michal Hocko SUSE Labs