linux-kernel - Re: [PATCH] mm: vmpressure: don't count userspace-induced reclaim as memory pressure

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: <YrmjH2FZF7iNn8da@dhcp22.suse.cz>
Date:   Mon, 27 Jun 2022 14:31:27 +0200
From:   Michal Hocko <mhocko@...e.com>
To:     Yosry Ahmed <yosryahmed@...gle.com>
Cc:     Shakeel Butt <shakeelb@...gle.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Roman Gushchin <roman.gushchin@...ux.dev>,
        Muchun Song <songmuchun@...edance.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Matthew Wilcox <willy@...radead.org>,
        Vlastimil Babka <vbabka@...e.cz>,
        David Hildenbrand <david@...hat.com>,
        Miaohe Lin <linmiaohe@...wei.com>, NeilBrown <neilb@...e.de>,
        Alistair Popple <apopple@...dia.com>,
        Suren Baghdasaryan <surenb@...gle.com>,
        Peter Xu <peterx@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Cgroups <cgroups@...r.kernel.org>, Linux-MM <linux-mm@...ck.org>
Subject: Re: [PATCH] mm: vmpressure: don't count userspace-induced reclaim as
 memory pressure

On Mon 27-06-22 02:39:49, Yosry Ahmed wrote:
[...]
> (a) Do not count vmpressure for mem_cgroup_resize_max() and
> mem_cgroup_force_empty() in v1.

yes, unless you have a very good reason to change that. E.g. this has
been buggy and we have finally understood that. But I do not see any
indications so far.

> (b) Do not count vmpressure (consequently,
> mem_cgroup_under_socket_pressure()) in v2 where psi is not counted
> (writing to memory.max, memory.high, and memory.reclaim).

I can see clear arguments for memory.reclaim opt out for vmpressure
because we have established that this is not a measure to express a
memory pressure on the cgroup.

Max/High are less clear to me, TBH. I do understand reasoning for PSI
exclusion because considering the calling process to be stalled and
non-productive is misleading. It just does its work so in a way it is
a productive time in the end. For the vmpressure, which measures how
hard/easy it is to reclaim memory why this should special for this
particular reclaim?

Again, an explanation of the effect on the socket pressure could give a
better picture. Say that I somebody reduces the limit (hard/high) and it
takes quite some effort to shrink the consumption down. Should the
networking layer react to that in any way or should it wait for the
active allocation during that process to find that out?
-- 
Michal Hocko
SUSE Labs