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 X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 13F77C48BDF for ; Tue, 15 Jun 2021 11:52:01 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9987D6145B for ; Tue, 15 Jun 2021 11:52:00 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9987D6145B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 3C5406B0036; Tue, 15 Jun 2021 07:52:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 39BEC6B006E; Tue, 15 Jun 2021 07:52:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 23D5C6B0070; Tue, 15 Jun 2021 07:52:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0238.hostedemail.com [216.40.44.238]) by kanga.kvack.org (Postfix) with ESMTP id E46656B0036 for ; Tue, 15 Jun 2021 07:51:59 -0400 (EDT) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 81F2A8249980 for ; Tue, 15 Jun 2021 11:51:59 +0000 (UTC) X-FDA: 78255794358.01.12EF887 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf04.hostedemail.com (Postfix) with ESMTP id 24B33548 for ; Tue, 15 Jun 2021 11:51:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1623757918; 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: in-reply-to:in-reply-to:references:references; bh=BF7n2UuNgLsoB3IPYKLpL2scAhDvByYXMdJbqiB7sPM=; b=GTR8xVKoekkgNNHC1MyLc3It2Ry3EHPls8DBvJhU2/mjVM+C0T1aNjMM2bcFVNLFmqm9Yq PEAzeyDCM3e70YFHCGNRMRa7lWviyJpJ4bItaw11klMRaRWefCaU5iEIFq5RE9wqPHuNLg NFr/MidmOT4Mv6H2gRHPEZsF/2YP8DY= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-354-pc4u9wa3OvSYtBVctfg8rA-1; Tue, 15 Jun 2021 07:51:49 -0400 X-MC-Unique: pc4u9wa3OvSYtBVctfg8rA-1 Received: by mail-wr1-f69.google.com with SMTP id y12-20020adffa4c0000b0290119c11bd29eso5845780wrr.2 for ; Tue, 15 Jun 2021 04:51:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=BF7n2UuNgLsoB3IPYKLpL2scAhDvByYXMdJbqiB7sPM=; b=IjThkgcAGONYSyvLCwElFQ+ZCdY0W2K7SPUaid06zDuZernJuGIE7AWtB+MIlFtbIR WWD+XnqQk+kQPIBhPlum9pE7GSlCk8AGUxwwP3tB3f9h0EU3rb8MkHVycqCTdwk+8Ppc Fv+eN/j/oAWfgw699cMDqQw3RPmsQQwn58vQkyW7mXL0m+S5NVEJJLp/WheAJIKzksn9 VApnjiC7KjqF0aNoxUSdqWIdHTQ3WMcA+qtD6/nx/Zk/mOgq3VdGOe6S0Rjr3ZLW0D15 C9gvnNm4bp71PlGiFuMkKIAcF19h9ktaCUii5GlNWBOriDJgvRo7B5zNpdTzAvRFNJ3Z Jang== X-Gm-Message-State: AOAM530BfO5r/ByxOUPEcTNUvWMoAnZAEMS9uAuqxWUWhpxsinenbqAk /y0nMx13euGCzs1bukpHAjlWI2tt3f8eNEDYmuj/d3Yu65WIOmF0whGStZ2AoPBIcLW6xaff3vf mvPnsyhTlsA== X-Received: by 2002:a5d:528d:: with SMTP id c13mr24933429wrv.343.1623757908660; Tue, 15 Jun 2021 04:51:48 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwfrXdXPcUnrA3LY/bXhSZrn+yM5Dpd1VpfejXuXn6BQ50zJcqr17XLR/nC4m+K03sHwlFpPQ== X-Received: by 2002:a5d:528d:: with SMTP id c13mr24933416wrv.343.1623757908490; Tue, 15 Jun 2021 04:51:48 -0700 (PDT) Received: from localhost (cpc111743-lutn13-2-0-cust979.9-3.cable.virginm.net. [82.17.115.212]) by smtp.gmail.com with ESMTPSA id w8sm19698515wre.70.2021.06.15.04.51.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Jun 2021 04:51:48 -0700 (PDT) Date: Tue, 15 Jun 2021 12:51:47 +0100 From: Aaron Tomlin To: Michal Hocko Cc: linux-mm@kvack.org, akpm@linux-foundation.org, vbabka@suse.cz, penguin-kernel@i-love.sakura.ne.jp, llong@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] mm/oom_kill: show oom eligibility when displaying the current memory state of all tasks Message-ID: <20210615115147.gp3w5bcjoaarvyse@ava.usersys.com> X-PGP-Key: http://pgp.mit.edu/pks/lookup?search=atomlin%40redhat.com X-PGP-Fingerprint: 7906 84EB FA8A 9638 8D1E 6E9B E2DE 9658 19CC 77D6 References: <20210612204634.1102472-1-atomlin@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 24B33548 Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=GTR8xVKo; spf=none (imf04.hostedemail.com: domain of atomlin@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=atomlin@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Stat-Signature: d6jg881uzhm59y4na9bird4ys7ycqjgs X-HE-Tag: 1623757912-337539 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon 2021-06-14 08:44 +0200, Michal Hocko wrote: > Well, I have to say that I have a bit hard time understand the problem > statement here. First of all you are very likely basing your observation > on an old kernel which is missing a fix which should make the situation > impossible IIRC. You should be focusing on a justification why the new > information is helpful for the current tree. Michal, Not exactly. See oom_reap_task(). Let's assume an OOM event occurred within the context of a memcg and 'memory.oom.group' was not set. If I understand correctly, once all attempts to OOM reap the specified task were "unsuccessful" then MMF_OOM_SKIP is applied; and, the assumption is it will be terminated shorty due to the pending fatal signal (see __oom_kill_process()) i.e. a SIGKILL is sent to the "victim" before the OOM reaper is notified. Now assuming the above task did not exited yet, another task, in the same memcg, could also trigger an OOM event. Therefore, when showing potential OOM victims the task above with MMF_OOM_SKIP set, will indeed be displayed. I understanding the point on OOM_SCORE_ADJ_MIN. This can be easily identified and is clear to the viewer. However, the same cannot be stated for MMF_OOM_SKIP. So, if we prefer to display rather than exclude such tasks, in my opinion having a flag/or marker of some description might prove useful to avoid any misunderstanding. > This should provide an example of the output with a clarification of the > meaning. Fair enough. Kind regards, -- Aaron Tomlin