linux-kernel - Re: [RFC v2] memcg: add memcg lru for page reclaiming

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

Message-ID: <20191029083730.GC31513@dhcp22.suse.cz>
Date:   Tue, 29 Oct 2019 09:37:30 +0100
From:   Michal Hocko <mhocko@...nel.org>
To:     Hillf Danton <hdanton@...a.com>
Cc:     linux-mm <linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Chris Down <chris@...isdown.name>, Tejun Heo <tj@...nel.org>,
        Roman Gushchin <guro@...com>,
        Johannes Weiner <hannes@...xchg.org>,
        Shakeel Butt <shakeelb@...gle.com>,
        Matthew Wilcox <willy@...radead.org>,
        Minchan Kim <minchan@...nel.org>, Mel Gorman <mgorman@...e.de>
Subject: Re: [RFC v2] memcg: add memcg lru for page reclaiming

On Sat 26-10-19 19:07:45, Hillf Danton wrote:
> 
> Currently soft limit reclaim is frozen, see
> Documentation/admin-guide/cgroup-v2.rst for reasons.
> 
> This work adds memcg hook into kswapd's logic to bypass slr,
> paving a brick for its cleanup later.
> 
> After b23afb93d317 ("memcg: punt high overage reclaim to
> return-to-userland path"), high limit breachers are reclaimed one
> after another spiraling up through the memcg hierarchy before
> returning to userspace.
> 
> We can not add new hook yet if it is infeasible to defer that
> reclaiming a bit further until kswapd becomes active.
> 
> It can be defered however because high limit breach looks benign
> in the absence of memory pressure, or we ensure it will be
> reclaimed soon in the presence of kswapd.

This is not true and I have already expressed that in a responsoce to
the v1 of this patch. Let me repeat (for the last time hopefully) the
high limit is aimed at throttling allocators even when the system is not
under a memory pressure. So no, we cannot defer to kswapd.

This patchset is ignoring the previous review feedback. You still
haven't described any real usecase and any reasons why the existing
feature list doesn't satisfy it.

Until this is sorted out:
Nacked-by: Michal Hocko <mhocko@...e.com>
-- 
Michal Hocko
SUSE Labs