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 2BC02C433EF for ; Fri, 8 Apr 2022 09:40:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B4AC06B0071; Fri, 8 Apr 2022 05:40:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B208F6B0072; Fri, 8 Apr 2022 05:40:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E97C6B0074; Fri, 8 Apr 2022 05:40:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0248.hostedemail.com [216.40.44.248]) by kanga.kvack.org (Postfix) with ESMTP id 908C26B0071 for ; Fri, 8 Apr 2022 05:40:17 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 2A0FF830F728 for ; Fri, 8 Apr 2022 09:40:17 +0000 (UTC) X-FDA: 79333216074.23.F072706 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf03.hostedemail.com (Postfix) with ESMTP id A308520003 for ; Fri, 8 Apr 2022 09:40:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1649410816; 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=JYCqI2SE1+yxHN/rLqWe+JaeAZMuu0aWZKyvaN+2uVc=; b=ekBS+2d7w5bFRLXF0djklWKRLrJQKRMoCJBF4nzNsXJWH8Lzm7as453IAAHLrl0HoGt9oz RIlvYjL6+SiP2KPjCNNhD5DfD5mBEfyhNXFH4zyx3aW55WNUbwoJ2tt97paZ1bSaFRmf9m DJW2ay2FndpoSdfvm62wXmpHoboYhYY= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-553-C1GpA2RYM8eYUd91b9SkNw-1; Fri, 08 Apr 2022 05:40:12 -0400 X-MC-Unique: C1GpA2RYM8eYUd91b9SkNw-1 Received: by mail-qk1-f200.google.com with SMTP id c19-20020a05620a0cf300b005f17891c015so3256207qkj.18 for ; Fri, 08 Apr 2022 02:40:12 -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=JYCqI2SE1+yxHN/rLqWe+JaeAZMuu0aWZKyvaN+2uVc=; b=1rTFT+SwugCW6DOkW2ASZto7q+EmoWALvhcpdFtsck3s7inI73X+r0Vt5fARDGNIes clHnEfOxXwSCGFKZemeLbybGbP8jmcPbCvgmQFPWbnRekLMyU6nl0odEmn+0+4rzbUKL q60d7GTHDTikpYStCaJrln2lTlVduVGg6xjfY+cq1aIPnGcIRKWn7dKppOexXiQ19hOF icq83GU2I3NpsxqIcu0stwSl16Vw7AZ9kxI8c36Czkaxbm3nD5NfhYRFNw+VSdF2ynke FmcNSj13NqWQS9LwqX9mQxuAuC5N84dnICFwm55MPNe6Vo6Wi9rY4EebEfKbnWPptn+N 7s0g== X-Gm-Message-State: AOAM533iMbMVVduAcaiCmOW9Wqd3WrMpOLjaYk0ToKokcPHVGDFrwg0p j/5ZJSCS2qYdvmjm3gC+UNhBbQw0BI0/cuk2nI7Z6H1eu1t7Md6Pt4RscY5Uxk/dPsmFiJzPhWS ZA6Mrb6UuS8s= X-Received: by 2002:a05:620a:484:b0:67e:16fe:3689 with SMTP id 4-20020a05620a048400b0067e16fe3689mr11750577qkr.745.1649410811810; Fri, 08 Apr 2022 02:40:11 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxFf8q2Jank8eDGXSNXYQcm5a45Gsr/FBZVdsaqB5SC5uEdpC/5YfsZauHF62EuAyLms4Ef6g== X-Received: by 2002:a05:620a:484:b0:67e:16fe:3689 with SMTP id 4-20020a05620a048400b0067e16fe3689mr11750568qkr.745.1649410811614; Fri, 08 Apr 2022 02:40:11 -0700 (PDT) Received: from [192.168.0.188] ([24.48.139.231]) by smtp.gmail.com with ESMTPSA id b21-20020a05620a04f500b0067b4895472esm13405172qkh.5.2022.04.08.02.40.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Apr 2022 02:40:11 -0700 (PDT) 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 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> 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: axks7o11bci6ei3ii754exdtjmnj94ta Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ekBS+2d7; spf=none (imf03.hostedemail.com: domain of npache@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=npache@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: A308520003 X-HE-Tag: 1649410816-948826 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 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