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 2C474C433EF for ; Fri, 8 Apr 2022 11:26:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A0F4B6B0071; Fri, 8 Apr 2022 07:26:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9BE0E6B0072; Fri, 8 Apr 2022 07:26:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 85EF36B0074; Fri, 8 Apr 2022 07:26:14 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0066.hostedemail.com [216.40.44.66]) by kanga.kvack.org (Postfix) with ESMTP id 783FD6B0071 for ; Fri, 8 Apr 2022 07:26:14 -0400 (EDT) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 21F2A183EE7A0 for ; Fri, 8 Apr 2022 11:26:14 +0000 (UTC) X-FDA: 79333483068.30.420CB32 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf16.hostedemail.com (Postfix) with ESMTP id 46C11180006 for ; Fri, 8 Apr 2022 11:26:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1649417172; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=N5RmUko8chmmbpF4Ji2OPWgXGC1cKNF9K4kHmP4gvcU=; b=WeyVymqO0TknmkUNuJ1oZaAhb+VMTGg8p06RHUOVeK64plFYgnJQ9PTQonjvcs6iGza21v mem7d6U6BodMXR5tyREeXr6+78IhUEKyKSwHVu1LyhpFXmguF9gWnRFVBdSOAGay2SF/EQ yvfsRlHoTiZGcL1Cj89+MLNnu/UqAj0= Received: from mail-qt1-f197.google.com (mail-qt1-f197.google.com [209.85.160.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-219-YNAlYF1QO3u3BEHsxajy1Q-1; Fri, 08 Apr 2022 07:26:10 -0400 X-MC-Unique: YNAlYF1QO3u3BEHsxajy1Q-1 Received: by mail-qt1-f197.google.com with SMTP id t22-20020ac87616000000b002ebdc95345cso2255964qtq.11 for ; Fri, 08 Apr 2022 04:26:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=N5RmUko8chmmbpF4Ji2OPWgXGC1cKNF9K4kHmP4gvcU=; b=vh/wdocmVBEsOqeyuvFiJbrHtv2BrloP1NP6g//u5He6hnNa9WY2wDWybaf2HeM4KG QDgLm64hIMYhYY0hOOnOBcuB3Gl/NiQ3jm9q8L+iI7A7UmSopmMtW5mtY5UDu6MhhEPl 2GkHTfs7zSvCs3GYBw1e9OWBttTkF8LA05i7olRfSevzdO/Vn5BGLU0YRYEsfmfanKKw 0nTPz2fRgVDbrsFdBPXCE2gxU1NqcBa1NilMyqR6A9kCS4bz4bqL+vE+0ONmgSCKXovG lCIKNUGj2uE5aSwpQ+tq+ZFXOoJVev4SWIgtGGfRYd0JDAJdmiUrXtVsNCisH2xys7CX BC3A== X-Gm-Message-State: AOAM532n+yoQWSzizxvBUWs/ub6tIkFQPwRH7jwS8P1A9oRmRudFWl1Z nOwny8OrP+GB7OEbsKwJVaJ1DAzXogWO009Ewpu+uf5QWPFfhsptO/aHS3NZo+B2zNzLxGAkTPc IW9J43sSMv6k= X-Received: by 2002:ac8:7f08:0:b0:2ed:c19:978a with SMTP id f8-20020ac87f08000000b002ed0c19978amr891916qtk.103.1649417170307; Fri, 08 Apr 2022 04:26:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxez04CIpHitABz4fWGxSWgbvqTgZzsGnrGwOJR0AO9QT/DXc8WFgXGa6ZHPQMrSCvSSlD2/w== X-Received: by 2002:ac8:7f08:0:b0:2ed:c19:978a with SMTP id f8-20020ac87f08000000b002ed0c19978amr891893qtk.103.1649417170042; Fri, 08 Apr 2022 04:26:10 -0700 (PDT) Received: from [192.168.0.188] ([24.48.139.231]) by smtp.gmail.com with ESMTPSA id h8-20020ac87d48000000b002e1c6faae9csm18310028qtb.28.2022.04.08.04.26.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Apr 2022 04:26:09 -0700 (PDT) Message-ID: <465ab95b-3e71-5901-c184-812dc595af2f@redhat.com> Date: Fri, 8 Apr 2022 07:26:07 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v8] oom_kill.c: futex: Don't OOM reap the VMA containing the robust_list_head To: Michal Hocko 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 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> From: Nico Pache In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Stat-Signature: czt7o1nbkny7xnuc1537mihbsoknz3jn X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 46C11180006 Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=WeyVymqO; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf16.hostedemail.com: domain of npache@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=npache@redhat.com X-Rspam-User: X-HE-Tag: 1649417173-412473 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 4/8/22 06:51, Michal Hocko wrote: > 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. Ok I see that now. I did my bit math incorrectly the first time around. I thought abort lead to the !oc->chosen case. > 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. Ok so if i understand that correctly, delaying can have some ugly effects and kinda breaks the initial purpose of the OOM reaper? I personally don't like the delay approach. Especially if we have a better one we know is working, and that doesnt add regressions. If someone can prove to me the private lock case, I'd be more willing to bite. Thanks for all the OOM context :) -- Nico