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 911F2C47082 for ; Mon, 7 Jun 2021 19:57:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 41F5160FF4 for ; Mon, 7 Jun 2021 19:57:21 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 41F5160FF4 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id F3D946B0073; Mon, 7 Jun 2021 15:57:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EE0B76B0078; Mon, 7 Jun 2021 15:57:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BF6266B0074; Mon, 7 Jun 2021 15:57:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0089.hostedemail.com [216.40.44.89]) by kanga.kvack.org (Postfix) with ESMTP id 847656B0073 for ; Mon, 7 Jun 2021 15:57:19 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 1E568181AF5D3 for ; Mon, 7 Jun 2021 19:57:19 +0000 (UTC) X-FDA: 78227986998.14.FBFF77E Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf10.hostedemail.com (Postfix) with ESMTP id F136F4229BBD for ; Mon, 7 Jun 2021 19:56:59 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 3F5C4219BF; Mon, 7 Jun 2021 19:47:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1623095239; 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=TOi1KB6lja6UnRpVQU3eb/l3MsV0mm06Av/9CJInWhg=; b=C08xuK/sEVIO8LHSIswJfmSbcS1WZIAMfmXpqBDcdBran4ge0viWHfL5V1uyd0cIrySnq1 Yckx2wMALbD8ik54qxJ/P8mZNEqw15I4e7FRN03PEG03RLC6ILqk761L/juXisuG84yHNl w/IfcoJ5kagufdP4l3tZ5f2F2lE2oyc= 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 EFA5AA3BD2; Mon, 7 Jun 2021 19:47:18 +0000 (UTC) Date: Mon, 7 Jun 2021 21:47:17 +0200 From: Michal Hocko To: Waiman Long Cc: Aaron Tomlin , linux-mm@kvack.org, akpm@linux-foundation.org, vbabka@suse.cz, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] mm/oom_kill: allow oom kill allocating task for non-global case Message-ID: References: <20210607163103.632681-1-atomlin@redhat.com> <8a6b57d1-b8dd-bf67-92c8-0421623f54ea@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8a6b57d1-b8dd-bf67-92c8-0421623f54ea@redhat.com> Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="C08xuK/s"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf10.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-Stat-Signature: x9dpbutt986cbxcmzhnnqphmp1wutkxz X-Rspamd-Queue-Id: F136F4229BBD X-Rspamd-Server: rspam06 X-HE-Tag: 1623095819-995721 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 Mon 07-06-21 15:26:00, Waiman Long wrote: > On 6/7/21 3:01 PM, Michal Hocko wrote: > > On Mon 07-06-21 17:31:03, Aaron Tomlin wrote: > > > At the present time, in the context of memcg OOM, even when > > > sysctl_oom_kill_allocating_task is enabled/or set, the "allocating" > > > task cannot be selected, as a target for the OOM killer. > > > > > > This patch removes the restriction entirely. > > This is a global oom policy not a memcg specific one so a historical > > behavior would change. So I do not think we can change that. The policy > > can be implemented on the memcg level but this would require a much more > > detailed explanation of the usecase and the semantic (e.g. wrt. > > hierarchical behavior etc). > > Maybe we can extend the meaning of oom_kill_allocating_task such that memcg > OOM killing of allocating task is only enabled when bit 1 is set. So if an > existing application just set oom_kill_allocating_task to 1, it will not be > impacted. panic_on_oom is already allowing to implement originally global policy to memcg. So if anything this policy should follow the same interface but still I think what you are seeing is either a bug or something else (e.g. the task being migrated while the oom is ongoing) and this should be properly investigated and explained. We cannot simply paper it over by telling people to use oom_kill_allocating_task to work it around. If there is a real usecase for such a policy for memcg oom killing can be discussed of course. -- Michal Hocko SUSE Labs