Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <676fb197-d045-c537-c1f7-e18320a6d15f@redhat.com>
Date:   Fri, 8 Apr 2022 05:40:09 -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
Content-Language: en-US
To:     Michal Hocko <mhocko@suse.com>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Peter Zijlstra <peterz@infradead.org>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, Rafael Aquini <aquini@redhat.com>,
        Waiman Long <longman@redhat.com>, Baoquan He <bhe@redhat.com>,
        Christoph von Recklinghausen <crecklin@redhat.com>,
        Don Dutile <ddutile@redhat.com>,
        "Herton R . Krzesinski" <herton@redhat.com>,
        David Rientjes <rientjes@google.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Davidlohr Bueso <dave@stgolabs.net>,
        Ingo Molnar <mingo@redhat.com>,
        Joel Savitz <jsavitz@redhat.com>,
        Darren Hart <dvhart@infradead.org>, stable@kernel.org
References: <20220408032809.3696798-1-npache@redhat.com>
 <20220408081549.GM2731@worktop.programming.kicks-ass.net>
 <87tub4j7hg.ffs@tglx> <ddf1755e-fe69-b60e-ee07-e78d663b11b2@redhat.com>
 <YlACJMp7AFaVa/Gt@dhcp22.suse.cz>
From:   Nico Pache <npache@redhat.com>
In-Reply-To: <YlACJMp7AFaVa/Gt@dhcp22.suse.cz>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk


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?

-- Nico