linux-kernel - Re: [RFC PATCH] memcg: use root_mem

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 for Android: free password hash cracker in your pocket

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

Date:   Mon, 22 Aug 2022 13:31:47 +0200
From:   Michal Hocko <mhocko@...e.com>
To:     Tejun Heo <tj@...nel.org>
Cc:     Shakeel Butt <shakeelb@...gle.com>,
        "zhaoyang.huang" <zhaoyang.huang@...soc.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Zhaoyang Huang <huangzhaoyang@...il.com>,
        Linux MM <linux-mm@...ck.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Cgroups <cgroups@...r.kernel.org>, ke.wang@...soc.com,
        Zefan Li <lizefan.x@...edance.com>,
        Roman Gushchin <roman.gushchin@...ux.dev>,
        Muchun Song <songmuchun@...edance.com>
Subject: Re: [RFC PATCH] memcg: use root_mem_cgroup when css is inherited

On Fri 19-08-22 07:10:26, Tejun Heo wrote:
> On Fri, Aug 19, 2022 at 10:08:59AM -0700, Shakeel Butt wrote:
> > On Fri, Aug 19, 2022 at 9:29 AM Tejun Heo <tj@...nel.org> wrote:
> > >
> > > On Fri, Aug 19, 2022 at 07:29:22PM +0800, zhaoyang.huang wrote:
> > > > From: Zhaoyang Huang <zhaoyang.huang@...soc.com>
> > > >
> > > > It is observed in android system where per-app cgroup is demanded by freezer
> > > > subsys and part of groups require memory control. The hierarchy could be simplized
> > > > as bellowing where memory charged on group B abserved while we only want have
> > > > group E's memory be controlled and B's descendants compete freely for memory.
> > > > This should be the consequences of unified hierarchy.
> > > > Under this scenario, less efficient memory reclaim is observed when comparing
> > > > with no memory control. It is believed that multi LRU scanning introduces some
> > > > of the overhead. Furthermore, page thrashing is also heavier than global LRU
> > > > which could be the consequences of partial failure of WORKINGSET mechanism as
> > > > LRU is too short to protect the active pages.
> > > >
> > > > A(subtree_control = memory) - B(subtree_control = NULL) - C()
> > > >                                                       \ D()
> > > >                           - E(subtree_control = memory) - F()
> > > >                                                         \ G()
> > > >
> > > > Signed-off-by: Zhaoyang Huang <zhaoyang.huang@...soc.com>
> > >
> > > Just in case it wasn't clear.
> > >
> > > Nacked-by: Tejun Heo <tj@...nel.org>
> > >
> > > Thanks.
> > >
> > 
> > Was there a previous discussion on this? The commit message is unreadable.
> 
> http://lkml.kernel.org/r/1660298966-11493-1-git-send-email-zhaoyang.huang@unisoc.com

Even that discussion doesn't really explain the real underlying problem.
There are statements about inefficiency and trashing without any further
details or clarifications.

My very vague understanding is that the Android system would like to
freeze specific applications and for that it requires each application
to live in its own cgroup. This clashes with a requirement to age and
reclaim memory on a different granularity (aka no per process reclaim).
So in fact something that cgroup v1 would achieve by having 2
hierarchies, one for the freezer which would have a dedicated cgroup for
each application and the other for the memory controller where tasks are
grouped by a different criteria. This would rule out that a global (or
any external memory pressure) reclaim would age LRUs that contain a mix
bag of application pages rather than iterate over per-application LRUs.
Is that understanding correct?
-- 
Michal Hocko
SUSE Labs