linux-kernel - Re: [PATCH] mm: memcontrol: avoid workload stalls when lowering memory.high

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] [day] [month] [year] [list]

Message-ID: <20200715165402.GA232052@cmpxchg.org>
Date:   Wed, 15 Jul 2020 12:54:02 -0400
From:   Johannes Weiner <hannes@...xchg.org>
To:     Shakeel Butt <shakeelb@...gle.com>
Cc:     Yang Shi <yang.shi@...ux.alibaba.com>,
        Roman Gushchin <guro@...com>, Michal Hocko <mhocko@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux MM <linux-mm@...ck.org>,
        Kernel Team <kernel-team@...com>,
        LKML <linux-kernel@...r.kernel.org>,
        Domas Mituzas <domas@...com>, Tejun Heo <tj@...nel.org>,
        Chris Down <chris@...isdown.name>
Subject: Re: [PATCH] mm: memcontrol: avoid workload stalls when lowering
 memory.high

On Tue, Jul 14, 2020 at 10:06:32AM -0700, Shakeel Butt wrote:
> On Tue, Jul 14, 2020 at 8:39 AM Johannes Weiner <hannes@...xchg.org> wrote:
> > The way we do this right now is having the reclaimer daemon in a
> > dedicated top-level cgroup with memory.min protection.
> >
> > This works well because we have a comprehensive cgroup setup anyway
> > and need to protect this daemon (it's oomd - the proactive reclaimer,
> > senpai, is a plugin) for other reasons as well. But it's probably a
> > royal pain to use if you don't have all of that infrastructure.
> >
> > One possible idea to make this simpler would be to have a limit knob
> > that has a psi/pressure blowout valve. This way you could specify your
> > tolerances for paging and what constitutes "cold" memory, and the
> > limit unsets itself when pressure moves into harmful territory. This
> > would make it safe to use when the reclaimer becomes unresponsive or
> > dies altogether, which makes it safe to use from within the
> > cgroup. And being separate from max and high means we can delegate it.
> 
> I like this idea and agree with having a separate interface from max
> and high. Though why do we want to think of this interface as a limit
> interface. Are there additional benefits or use-cases which can
> benefit from this semantic?

I'm not saying we have to.

But one benefit of having a limit rather than a reclaim command knob
is that you can prevent cache-polluting scans through file data from
unnecessarily exploding the memory footprint of the cgroup.

It may be useful to compile a list of applications and goals for such
a knob, i.e. the reasons we want to do proactive reclaim in the first
place.