Received: by 10.223.176.46 with SMTP id f43csp1233457wra; Fri, 26 Jan 2018 14:21:11 -0800 (PST) X-Google-Smtp-Source: AH8x2277psWf5u7yPyrnN7WmAxQWv6EXiqYVfYh8JkeMEi7YCrcWvFlsQURnoFoXzGodR1L5/XML X-Received: by 10.101.80.69 with SMTP id k5mr5697673pgo.435.1517005270938; Fri, 26 Jan 2018 14:21:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517005270; cv=none; d=google.com; s=arc-20160816; b=tP1J9zC7giw4QP7VMNivMNBYCzZLDDOrSBt2IALA7q0xSombT9opB5dgfTZmSzBNPJ bUD4Wj2bdkO72J4mbdmXIPmWR+ZJbOVUtu3IZyklp6TBxjjjE3b+1EELWLmArpwKrWJP ycn0M6Kkx1DjxtObg1Li6agKuFA5QWjkxzvXnbjqWOfmCQnOiJoWEu3dH5x+pR98oA68 0ShFVZntK4zzDeYVPqPaNSsKowgVdtE9QDoA5F0hRLyRiy9KtgVG+6Zp188D4AVz/Vsa j+zToFBc8Nbzr7wYLZHoKcZl146tn5wBUuo2LDwOB4O1hxBz/tlOHsXCKlZNJ5T0dnga 1KPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=THloCuCWF6Cbi88W4QzKu+8PLTls7eSLfGfee97GoAA=; b=uMP6rOjalM97IYsqSSrMb2r2/7I2CK6H2jW6wTpD72QwP1OMAYCTNtC1ZSwlHyRGjX e2TI/KmgqoIRIm+wMyNnuNJVZRo1w8m7XXp9o6DP5PxcmDee5ToFMaH1pVOv1YGeObcx 4RDHJIOqE+BdmpSTOOSW9MYMKl5/yp6KTVWiBkEioIsmjLw4Ez1blR19OgglMYuPRu7v yH78Xs7MbnWxDcFfma+BwdGhQixud1gb/CtKgNAdD7Ccn2ToxA9osj1UHBWYfXhWCa57 Pw0pwz5Pp2i9tdHU0PHHqho3b7zIamRACGBNRBI2kM4Uf28l9EsZ0hs7jChaB+hbT7g+ BEEQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Faia0L6J; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x13si3556732pgt.263.2018.01.26.14.20.56; Fri, 26 Jan 2018 14:21:10 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=Faia0L6J; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752128AbeAZWU3 (ORCPT + 99 others); Fri, 26 Jan 2018 17:20:29 -0500 Received: from mail-pf0-f194.google.com ([209.85.192.194]:34399 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751760AbeAZWU1 (ORCPT ); Fri, 26 Jan 2018 17:20:27 -0500 Received: by mail-pf0-f194.google.com with SMTP id e76so1174639pfk.1 for ; Fri, 26 Jan 2018 14:20:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=THloCuCWF6Cbi88W4QzKu+8PLTls7eSLfGfee97GoAA=; b=Faia0L6JAc+Y0RfWdC7t2mzrDGqh20dV44XmWyHx62ZSa9+lSzEhjxev/6Wxn6TYBd IH1JPZ/Pfq9ENd3isYXCKwfdz/odIkSuRn6ZG6D5P2Z8aW+clR+Bbm7VJ7lc5Gbwb8YI FEkDVtLCKATnWtTxhxp5dfL68zLWWfD6CHDzLaOT10RoYsqKeeRXlJ30QX5z9w8hZAH5 Y/lghw7k3Mtukeed2JFiS27tPQIvsXwrg+TgvFk0Q2b8NCZC1SjTM+YQw1+zeKcGZMno wICfgT/CSwRHYWqlHSipwnZ1sZZCTheryMBlnNYPl+TPqL2FDviIVk/xoBUQSqB0YgLR l4Cg== 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:in-reply-to:message-id :references:user-agent:mime-version; bh=THloCuCWF6Cbi88W4QzKu+8PLTls7eSLfGfee97GoAA=; b=qyamu54m0A9dgGBjHNfH5CMlHefWFg6+Qp06uJjB/oWaH9MP8XWgoNvTfvl7CB/Tpc 8fdEFoUfazlwAyxW4JXmWixbyLLiVcS+Dr1avkYK/G2TcUz6FvIFIF9bqjrGl50XsBQ+ LmpRsp2GrRqvzBQAnSJ0Dkw1r+xhOwUOGpi7KncU8gS/Ace3iPtPGPw9BvdcY0OuFz9b 5rJJixzCCQo4zubZOPkIeQuUQut6zYFAZq50vfgG/aDJ9pYnsaO62upxtT1HVL/L7M01 6GbpSGXtpRDkUA4dZzeBGiVx93ucgnLTRxwZm5fjeYOrLs8e457lZhgZBynvQ0bj9NOo 6mqA== X-Gm-Message-State: AKwxytc+XYK+kmRTJ3Dc0pdH6vwAVeOTKlGU4FvGfuEsL5JnJcvWMR8N kt2K1jbjeZOTtgUIqjysZry4IQ== X-Received: by 10.98.50.3 with SMTP id y3mr19851521pfy.98.1517005226207; Fri, 26 Jan 2018 14:20:26 -0800 (PST) Received: from [2620:15c:17:3:951d:d8da:c496:5667] ([2620:15c:17:3:951d:d8da:c496:5667]) by smtp.gmail.com with ESMTPSA id o135sm19717018pfg.161.2018.01.26.14.20.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 26 Jan 2018 14:20:25 -0800 (PST) Date: Fri, 26 Jan 2018 14:20:24 -0800 (PST) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Andrew Morton 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 In-Reply-To: <20180125160016.30e019e546125bb13b5b6b4f@linux-foundation.org> Message-ID: References: <20180125160016.30e019e546125bb13b5b6b4f@linux-foundation.org> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? Please note that this patchset is not only to remove a mount option, it is to allow oom policies to be configured per subtree such that users whom you delegate those subtrees to cannot evade the oom policy that is set at a higher level. The goal is to prevent the user from needing to organize their hierarchy is a specific way to work around this constraint and use things like limiting the number of child cgroups that user is allowed to create only to work around the oom policy. With a cgroup v2 single hierarchy it severely limits the amount of control the user has over their processes because they are locked into a very specific hierarchy configuration solely to not allow the user to evade oom kill. 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.