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=-1.0 required=3.0 tests=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 DCC31C43332 for ; Fri, 20 Mar 2020 13:44:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A372820722 for ; Fri, 20 Mar 2020 13:44:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A372820722 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 315276B0003; Fri, 20 Mar 2020 09:44:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2C4696B0006; Fri, 20 Mar 2020 09:44:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1D9956B0007; Fri, 20 Mar 2020 09:44:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 03F9B6B0003 for ; Fri, 20 Mar 2020 09:44:31 -0400 (EDT) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id B8839181AC9CC for ; Fri, 20 Mar 2020 13:44:31 +0000 (UTC) X-FDA: 76615860342.26.slip59_7eccb3f259e1a X-HE-Tag: slip59_7eccb3f259e1a X-Filterd-Recvd-Size: 5839 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Fri, 20 Mar 2020 13:44:31 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id h9so7514866wrc.8 for ; Fri, 20 Mar 2020 06:44:31 -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=JoMCT/BRNQiPNC0aagaWJkcjnStn6MMheHBwrTllAYE=; b=JL0mnoHFuwQ7WEJ1C7dnVAQdAZ3rbmf3IVBlWvCppdw4tIp42P/yFgvRAgHuVacieb yZYd1+ML9gVQFvcqvPreAwQFCkZysPiKm3kteMqRRA8tZpS768gmdRvbDa5CmLotLsRe ecvVU1xWYrtyQ1VNQGRAneFAQTgJv6+P76UfUkt6jFkL4q89D63kLgezEg6nfEfonZqU JOROHBk297YCavK0wuxX7sw/om6xhrBGf/tl0hjzbnjPRIohaurDosWpekIemPAtL5wy dWtQ29LGdX0bUyLL76YJEBWQgPoN9Ety2+BWgbE3egyTkjx+1/FdxhwYPQJuGHmAZn7p 30pw== X-Gm-Message-State: ANhLgQ14XLhUke4wice7WFg7U3qDD8iYXE8VLUdCy4EiuCyB6fEhlzwK Jkc4VIHw7VQa3X/hQNYxDWE= X-Google-Smtp-Source: ADFU+vvNQ+OVi0CDztzjk8c5YtCs3frJ0uwb28VpsQJngNtXMbSTyMNx7K5uLhR9puA4Gim3tpbQtg== X-Received: by 2002:adf:914e:: with SMTP id j72mr11378978wrj.109.1584711870045; Fri, 20 Mar 2020 06:44:30 -0700 (PDT) Received: from localhost (ip-37-188-140-107.eurotel.cz. [37.188.140.107]) by smtp.gmail.com with ESMTPSA id n63sm4850139wmf.6.2020.03.20.06.44.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Mar 2020 06:44:29 -0700 (PDT) Date: Fri, 20 Mar 2020 14:44:28 +0100 From: Michal Hocko To: Ivan Teterevkov Cc: "rientjes@google.com" , "willy@infradead.org" , "vbabka@suse.cz" , "tj@kernel.org" , "lizefan@huawei.com" , "hannes@cmpxchg.org" , "corbet@lwn.net" , "vdavydov.dev@gmail.com" , "akpm@linux-foundation.org" , "guro@fb.com" , "shakeelb@google.com" , "chris@chrisdown.name" , "yang.shi@linux.alibaba.com" , "tglx@linutronix.de" , "minchan@kernel.org" , "ying.huang@intel.com" , "ziqian.lzq@antfin.com" , "cgroups@vger.kernel.org" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Jonathan Davies Subject: Re: [RFC] memcg: fix default behaviour of non-overridden memcg.swappiness Message-ID: <20200320134428.GG24409@dhcp22.suse.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Thu 19-03-20 17:38:30, Ivan Teterevkov wrote: > This patch tries to resolve uncertainty around the memcg.swappiness when > it's not overridden by the user: shall there be the latest vm_swappiness > or the value captured at the moment when the cgroup was created? > > I'm sitting on the fence with regards to this patch because cgroup v1 is > considered legacy nowadays and the semantics of "swappiness" is already > overwhelmed. However, the patch might be considered as a "fix" because > looking at the documentation [1] one might have the impression that it's > the latest /proc/sys/vm/swappiness value that should be found in the > memcg.swappiness unless it's overridden or inherited from a cgroup where > it was overridden when the given cgroup was created. Could you be more specific what makes you think this? Let me quote the whole thing here : 5.3 swappiness : -------------- : : Overrides /proc/sys/vm/swappiness for the particular group. The tunable : in the root cgroup corresponds to the global swappiness setting. : : Please note that unlike during the global reclaim, limit reclaim : enforces that 0 swappiness really prevents from any swapping even if : there is a swap storage available. This might lead to memcg OOM killer : if there are no file pages to reclaim. I do not want to pick on words here but to me it sounds this tunable is clearly documented as the explicit override for the global value. The root memcg corresponds to the global limit because root tends to be special in many other aspects. But in general, the semantic of knobs is that they do not unexpectedly change their values without an explicit user/admin intervention. > > Also, shall this magic -1 be exposed to the user? I think it's a "no", > but what if the user wants to un-override the memcg.swappiness... If we are to use such a semantic then it absolutely has to be an opt-in behavior and expressed in some way to the user space (e.g. a symbolic name referring to the global setting). > > What do you reckon? I am not convinced we need it. There would have to be a real life usecase that cannot really work with the current semantic. I remember that this has been brought up when discussing early swappiness initialization [1]. But it seems there is a much better solution for that problem [2]. [1] http://lkml.kernel.org/r/BL0PR02MB560167492CA4094C91589930E9FC0@BL0PR02MB5601.namprd02.prod.outlook.com [2] http://lkml.kernel.org/r/20200317132105.24555-1-vbabka@suse.cz -- Michal Hocko SUSE Labs