[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87edgufakm.fsf@yhuang6-desk2.ccr.corp.intel.com>
Date: Mon, 13 Nov 2023 14:10:01 +0800
From: "Huang, Ying" <ying.huang@...el.com>
To: Huan Yang <link@...o.com>
Cc: Michal Hocko <mhocko@...e.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
Huan Yang <link@...o.com> writes:
> 在 2023/11/10 20:24, Michal Hocko 写道:
>> On Fri 10-11-23 11:48:49, Huan Yang wrote:
>> [...]
>>> Also, When the application enters the foreground, the startup speed
>>> may be slower. Also trace show that here are a lot of block I/O.
>>> (usually 1000+ IO count and 200+ms IO Time) We usually observe very
>>> little block I/O caused by zram refault.(read: 1698.39MB/s, write:
>>> 995.109MB/s), usually, it is faster than random disk reads.(read:
>>> 48.1907MB/s write: 49.1654MB/s). This test by zram-perf and I change a
>>> little to test UFS.
>>>
>>> Therefore, if the proactive reclamation encounters many file pages,
>>> the application may become slow when it is opened.
>> OK, this is an interesting information. From the above it seems that
>> storage based IO refaults are order of magnitude more expensive than
>> swap (zram in this case). That means that the memory reclaim should
>> _in general_ prefer anonymous memory reclaim over refaulted page cache,
>> right? Or is there any reason why "frozen" applications are any
>> different in this case?
> Frozen applications mean that the application process is no longer active,
> so once its private anonymous page data is swapped out, the anonymous
> pages will not be refaulted until the application becomes active again.
>
> On the contrary, page caches are usually shared. Even if the
> application that
> first read the file is no longer active, other processes may still
> read the file.
> Therefore, it is not reasonable to use the proactive reclamation
> interface to
> reclaim page caches without considering memory pressure.
No. Not all page caches are shared. For example, the page caches used
for use-once streaming IO. And, they should be reclaimed firstly.
So, your solution may work good for your specific use cases, but it's
not a general solution. Per my understanding, you want to reclaim only
private pages to avoid impact the performance of other applications.
Privately mapped anonymous pages is easy to be identified (And I suggest
that you can find a way to avoid reclaim shared mapped anonymous pages).
There's some heuristics to identify use-once page caches in reclaiming
code. Why doesn't it work for your situation?
[snip]
--
Best Regards,
Huang, Ying
Powered by blists - more mailing lists