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.8 required=3.0 tests=BAYES_00,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 17E13C48BE5 for ; Fri, 11 Jun 2021 06:55:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DE1ED61364 for ; Fri, 11 Jun 2021 06:55:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230230AbhFKG5r (ORCPT ); Fri, 11 Jun 2021 02:57:47 -0400 Received: from smtp-out2.suse.de ([195.135.220.29]:34258 "EHLO smtp-out2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230248AbhFKG5p (ORCPT ); Fri, 11 Jun 2021 02:57:45 -0400 Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 2E1631FD3F; Fri, 11 Jun 2021 06:55:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1623394547; 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=N2XJlMbDzn+ePfxRClY3gO0FkSnDmd58pgVQ6MHl3tc=; b=PCAPx+BwqsoG/XE8TBDIzCqULGdJAN2G7SFwSw8L9QIyY4yJlSK+MQ7MjNVvOm3X5Fisy8 GEPQ6bBMT1RAY99VdFqGe5HvS2k9xcZ+5UzLuAspyJ9l6JTntkWJaoDcdCoLpugh4qQ5qk mw6LSSH4Htk4HULGkTvBSvGIg8yj6hw= 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 4953AA3B87; Fri, 11 Jun 2021 06:55:46 +0000 (UTC) Date: Fri, 11 Jun 2021 08:55:45 +0200 From: Michal Hocko To: Tetsuo Handa Cc: Aaron Tomlin , Waiman Long , Shakeel Butt , Linux MM , Andrew Morton , Vlastimil Babka , LKML Subject: Re: [RFC PATCH] mm/oom_kill: allow oom kill allocating task for non-global case Message-ID: References: <353d012f-e8d4-c54c-b33e-54737e1a0115@redhat.com> <20210609143534.v65qknfihqimiivd@ava.usersys.com> <20210610122323.6geriip66jjmdstj@ava.usersys.com> <20210610133644.zpoqfvlchaey24za@ava.usersys.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu 10-06-21 23:06:47, Tetsuo Handa wrote: > On 2021/06/10 22:36, Aaron Tomlin wrote: > > On Thu 2021-06-10 14:43 +0200, Michal Hocko wrote: > >> Well, I am not sure this is a good thing in general. We do not want to > >> hide tasks. We already do display oom_score_adj_min even though they are > >> not eligible and that can serve a good purpose from my experience. It > >> gives us some picture at least. Maybe a flag to mark all uneligible > >> tasks would be something useful but I wouldn't drop them from the list. > > > > Fair enough. > > Yes, marking ineligible (i.e. oom_badness() returning LONG_MIN) tasks would be useful. > > By the way, was the task namely "node" (i.e. PID 1703345) multithreaded program? > Your kernel might want commit 7775face207922ea ("memcg: killed threads should not invoke memcg OOM killer"). Yes, this would help for multithreaded race situation indeed. Thanks! -- Michal Hocko SUSE Labs