linux-kernel - Re: [RFC] memcg: fix default behaviour of non-overridden memcg.swappiness

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200320134428.GG24409@dhcp22.suse.cz>
Date:   Fri, 20 Mar 2020 14:44:28 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Ivan Teterevkov <ivan.teterevkov@...anix.com>
Cc:     "rientjes@...gle.com" <rientjes@...gle.com>,
        "willy@...radead.org" <willy@...radead.org>,
        "vbabka@...e.cz" <vbabka@...e.cz>, "tj@...nel.org" <tj@...nel.org>,
        "lizefan@...wei.com" <lizefan@...wei.com>,
        "hannes@...xchg.org" <hannes@...xchg.org>,
        "corbet@....net" <corbet@....net>,
        "vdavydov.dev@...il.com" <vdavydov.dev@...il.com>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "guro@...com" <guro@...com>,
        "shakeelb@...gle.com" <shakeelb@...gle.com>,
        "chris@...isdown.name" <chris@...isdown.name>,
        "yang.shi@...ux.alibaba.com" <yang.shi@...ux.alibaba.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "minchan@...nel.org" <minchan@...nel.org>,
        "ying.huang@...el.com" <ying.huang@...el.com>,
        "ziqian.lzq@...fin.com" <ziqian.lzq@...fin.com>,
        "cgroups@...r.kernel.org" <cgroups@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Jonathan Davies <jond@...anix.com>
Subject: Re: [RFC] memcg: fix default behaviour of non-overridden
 memcg.swappiness

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