Received: by 10.223.176.46 with SMTP id f43csp1249164wra; Fri, 26 Jan 2018 14:41:48 -0800 (PST) X-Google-Smtp-Source: AH8x226aBXDKv97ZsIX0SSq2YXLPB/NZSBHEfah+Ht1BMEk4+qEF+SXM5znT2EgTLHj6/QdDWoxK X-Received: by 2002:a17:902:988b:: with SMTP id s11-v6mr14681547plp.99.1517006508361; Fri, 26 Jan 2018 14:41:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517006508; cv=none; d=google.com; s=arc-20160816; b=XrmpElCZwh6aLf1Dynw6Z8AD2fDh01JBJh9Vpl7aqL4HLK+S4mwNt9JQaAKxHGHldK Ijlo2wkIQzwYY3Ye0LCN8FqyhCREceg2Z1mbOkVPMleUKZoLOoMWMwX2kcB2R6ewzeUW PktbdxbuVBrLzpsITYwDyPg4lAddqyksc+NPlwjepHQltZTgSogzbHTvprWMfpVX/nWM EtquKI9zgNTfW/loQVgAkn3PAytyfmpldn1NOKwp5vEikRT7D6bOPE/Af2BfHhSQV7Ec QqIpfVOWWE6zULDF9DWzsWFZ3QtE6y4pa1kD4YUaxVtlkxamYxpB+y6VzzZX8BfYpZFx tfEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=z0m6f3NuZ0CR+a3u1Z5d7pGPYxl4xohg5l8G4OgpRNM=; b=e+79nTZ0+58e/Mb47O1X0it1z2KkHLCg+pywuVRMmnnKyO044CwovLRq1O1FJ/JdY+ 2Awv3RhKrr977kCO9pr5vOPjfl97Tndxuzww35jaIII8LqdtYFntGCoraQVAeVXmgdbH jiOygDRUSmJCL/iVQpy1ZnRg8HierGNoq5Nc7NYsfHgjQy0attEuol36SOOY4rQmI1XI 36GTvTUwmKBLtY1mQYXmvoocJW0lz8jNg8cpurk43zSG85ZturMOt7HPEJJoVsKx0rX1 jYS2Kr+r4v90SaXxW3a7zpbS7pcmiFhWgq/QNChsERPPNq8IFowQ60TeT8d2Ohktc+cs aZZA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id q10si3541755pgc.403.2018.01.26.14.41.34; Fri, 26 Jan 2018 14:41:48 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752229AbeAZWjx (ORCPT + 99 others); Fri, 26 Jan 2018 17:39:53 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:60646 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751674AbeAZWjw (ORCPT ); Fri, 26 Jan 2018 17:39:52 -0500 Received: from akpm3.svl.corp.google.com (unknown [104.133.9.92]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 3B1E1F63; Fri, 26 Jan 2018 22:39:51 +0000 (UTC) Date: Fri, 26 Jan 2018 14:39:50 -0800 From: Andrew Morton To: David Rientjes Cc: Roman Gushchin , Michal Hocko , Vladimir Davydov , Johannes Weiner , Tetsuo Handa , Tejun Heo , kernel-team@fb.com, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [patch -mm v2 2/3] mm, memcg: replace cgroup aware oom killer mount option with tunable Message-Id: <20180126143950.719912507bd993d92188877f@linux-foundation.org> In-Reply-To: References: <20180125160016.30e019e546125bb13b5b6b4f@linux-foundation.org> X-Mailer: Sylpheed 3.4.1 (GTK+ 2.24.23; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 26 Jan 2018 14:20:24 -0800 (PST) David Rientjes wrote: > On Thu, 25 Jan 2018, Andrew Morton wrote: > > > > Now that each mem cgroup on the system has a memory.oom_policy tunable to > > > specify oom kill selection behavior, remove the needless "groupoom" mount > > > option that requires (1) the entire system to be forced, perhaps > > > unnecessarily, perhaps unexpectedly, into a single oom policy that > > > differs from the traditional per process selection, and (2) a remount to > > > change. > > > > > > Instead of enabling the cgroup aware oom killer with the "groupoom" mount > > > option, set the mem cgroup subtree's memory.oom_policy to "cgroup". > > > > Can we retain the groupoom mount option and use its setting to set the > > initial value of every memory.oom_policy? That way the mount option > > remains somewhat useful and we're back-compatible? > > > > -ECONFUSED. We want to have a mount option that has the sole purpose of > doing echo cgroup > /mnt/cgroup/memory.oom_policy? Approximately. Let me put it another way: can we modify your patchset so that the mount option remains, and continues to have a sufficiently same effect? For backward compatibility. > This, and fixes to fairly compare the root mem cgroup with leaf mem > cgroups, are essential before the feature is merged otherwise it yields > wildly unpredictable (and unexpected, since its interaction with > oom_score_adj isn't documented) results as I already demonstrated where > cgroups with 1GB of usage are killed instead of 6GB workers outside of > that subtree. OK, so Roman's new feature is incomplete: it satisfies some use cases but not others. And we kinda have a plan to address the other use cases in the future. There's nothing wrong with that! As long as we don't break existing setups while evolving the feature. How do we do that?