linux-kernel - RE: [PATCH] mm/vmscan: add vm_swappiness configuration knobs

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: <BL0PR02MB5601F1945BADC0AF46FC3962E9F90@BL0PR02MB5601.namprd02.prod.outlook.com>
Date:   Mon, 16 Mar 2020 16:03:08 +0000
From:   Ivan Teterevkov <ivan.teterevkov@...anix.com>
To:     David Rientjes <rientjes@...gle.com>
CC:     Chris Down <chris@...isdown.name>,
        Matthew Wilcox <willy@...radead.org>,
        "corbet@....net" <corbet@....net>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "mchehab+samsung@...nel.org" <mchehab+samsung@...nel.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "jpoimboe@...hat.com" <jpoimboe@...hat.com>,
        "pawan.kumar.gupta@...ux.intel.com" 
        <pawan.kumar.gupta@...ux.intel.com>,
        "jgross@...e.com" <jgross@...e.com>,
        "oneukum@...e.com" <oneukum@...e.com>,
        "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>
Subject: RE: [PATCH] mm/vmscan: add vm_swappiness configuration knobs

On Fri, 13 Mar 2020, David Rientjes wrote:

> I'll renew my suggestion of defaulting memcg->swappiness to -1 and then
> letting mem_cgroup_swappiness() return vm_swappiness when
> memcg->swappiness == -1.
> 
> I don't think the act of creating a memcg and not initializing the
> swappiness value implies that the existing value meets your expectation.
> 
Thanks, David, I haven't considered this point.

This point has made me realising that the existing behaviour, where
the swappiness is inherited from the parent, is not documented and,
apparently, just appears to be implemented that way.

In this case, the -1 approach looks less harmful in comparison with
the original patch, unless I underestimate a number of users "affected"
by the assumptions about how memcg->swappiness is getting propagated.

I'll send another patch implementing the -1 approach shortly,
perhaps with some clarifications in the "swappiness" documentation.