Message-ID: <dcd2eff8-400b-4ade-a5b2-becfe26b437b@vivo.com>
Date:   Mon, 13 Nov 2023 09:54:55 +0800
From:   Huan Yang <link@...o.com>
To:     Michal Hocko <mhocko@...e.com>
Cc:     "Huang, Ying" <ying.huang@...el.com>, Tejun Heo <tj@...nel.org>,
        Zefan Li <lizefan.x@...edance.com>,
        Johannes Weiner <hannes@...xchg.org>,
        Jonathan Corbet <corbet@....net>,
        Roman Gushchin <roman.gushchin@...ux.dev>,
        Shakeel Butt <shakeelb@...gle.com>,
        Muchun Song <muchun.song@...ux.dev>,
        Andrew Morton <akpm@...ux-foundation.org>,
        David Hildenbrand <david@...hat.com>,
        Matthew Wilcox <willy@...radead.org>,
        Kefeng Wang <wangkefeng.wang@...wei.com>,
        Peter Xu <peterx@...hat.com>,
        "Vishal Moola (Oracle)" <vishal.moola@...il.com>,
        Yosry Ahmed <yosryahmed@...gle.com>,
        Liu Shixin <liushixin2@...wei.com>,
        Hugh Dickins <hughd@...gle.com>, cgroups@...r.kernel.org,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, opensource.kernel@...o.com
Subject: Re: [RFC 0/4] Introduce unbalance proactive reclaim


在 2023/11/10 20:32, Michal Hocko 写道:
> On Fri 10-11-23 14:21:17, Huan Yang wrote:
> [...]
>>> BTW: how do you know the number of pages to be reclaimed proactively in
>>> memcg proactive reclaiming based solution?
>> One point here is that we are not sure how long the frozen application
>> will be opened, it could be 10 minutes, an hour, or even days.  So we
>> need to predict and try, gradually reclaim anonymous pages in
>> proportion, preferably based on the LRU algorithm.  For example, if
>> the application has been frozen for 10 minutes, reclaim 5% of
>> anonymous pages; 30min:25%anon, 1hour:75%, 1day:100%.  It is even more
>> complicated as it requires adding a mechanism for predicting failure
>> penalties.
> Why would make your reclaiming decisions based on time rather than the
> actual memory demand? I can see how a pro-active reclaim could make a
> head room for an unexpected memory pressure but applying more pressure
> just because of inactivity sound rather dubious to me TBH. Why cannot
> you simply wait for the external memory pressure (e.g. from kswapd) to
> deal with that based on the demand?
Because the current kswapd and direct memory reclamation are a passive
memory reclamation based on the watermark, and in the event of triggering
these reclamation scenarios, the smoothness of the phone application cannot
be guaranteed. (We often observe that when the above reclamation is 
triggered,
there is a delay in the application startup, usually accompanied by 
block I/O, and
some concurrency issues caused by lock design.)

To ensure the smoothness of application startup, we have a module in 
Android called
LMKD (formerly known as lowmemorykiller). Based on a certain algorithm, LMKD
detects if application startup may be delayed and proactively kills 
inactive applications.
(For example, based on factors such as refault IO and swap usage.)

However, this behavior may cause the applications we want to protect to 
be killed,
which will result in users having to wait for them to restart when they 
are reopened,
which may affect the user experience.(For example, if the user wants to 
reopen the
application interface they are working on, or re-enter the order 
interface they were viewing.)

Therefore, the above proactive reclamation interface is designed to 
compress memory
types with minimal cost for upper-layer applications based on reasonable 
strategies,
in order to avoid triggering LMKD or memory reclamation as much as possible,
even if it is not balanced.

-- 
Thanks,
Huan Yang

Powered by blists - more mailing lists