Message-ID: <8cbee57b2d7a44339372be8c7c4f25bd@honor.com>
Date: Wed, 16 Oct 2024 01:25:58 +0000
From: gaoxu <gaoxu2@...or.com>
To: Barry Song <21cnbao@...il.com>
CC: David Hildenbrand <david@...hat.com>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"mhocko@...e.com" <mhocko@...e.com>, "hailong.liu@...o.com"
	<hailong.liu@...o.com>, "kaleshsingh@...gle.com" <kaleshsingh@...gle.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"lokeshgidra@...gle.com" <lokeshgidra@...gle.com>, "ngeoffray@...gle.com"
	<ngeoffray@...gle.com>, "shli@...com" <shli@...com>, "surenb@...gle.com"
	<surenb@...gle.com>, "yuzhao@...gle.com" <yuzhao@...gle.com>,
	"minchan@...nel.org" <minchan@...nel.org>, Barry Song <v-songbaohua@...o.com>
Subject: 回复: [PATCH RFC] mm: mglru: provide a separate list for lazyfree anon folios



> -----邮件原件-----
> 发件人: Barry Song <21cnbao@...il.com>
> 发送时间: 2024年10月16日 4:10
> 收件人: gaoxu <gaoxu2@...or.com>
> 抄送: David Hildenbrand <david@...hat.com>; akpm@...ux-foundation.org;
> linux-mm@...ck.org; mhocko@...e.com; hailong.liu@...o.com;
> kaleshsingh@...gle.com; linux-kernel@...r.kernel.org;
> lokeshgidra@...gle.com; ngeoffray@...gle.com; shli@...com;
> surenb@...gle.com; yuzhao@...gle.com; minchan@...nel.org; Barry Song
> <v-songbaohua@...o.com>
> 主题: Re: [PATCH RFC] mm: mglru: provide a separate list for lazyfree anon folios
> 
> On Tue, Oct 15, 2024 at 11:03 PM gaoxu <gaoxu2@...or.com> wrote:
> >
> > >
> > > On Wed, Sep 18, 2024 at 12:02 AM David Hildenbrand
> > > <david@...hat.com>
> > > wrote:
> > > >
> > > > On 14.09.24 08:37, Barry Song wrote:
> > > > > From: Barry Song <v-songbaohua@...o.com>
> > > > >
> > > > > This follows up on the discussion regarding Gaoxu's work[1].
> > > > > It's unclear if there's still interest in implementing a
> > > > > separate LRU list for lazyfree folios, but I decided to explore
> > > > > it out of curiosity.
> > > > >
> > > > > According to Lokesh, MADV_FREE'd anon folios are expected to be
> > > > > released earlier than file folios. One option, as implemented by
> > > > > Gao Xu, is to place lazyfree anon folios at the tail of the
> > > > > file's `min_seq` generation. However, this approach results in
> > > > > lazyfree folios being released in a LIFO manner, which conflicts
> > > > > with LRU behavior, as noted by Michal.
> > > > >
> > > > > To address this, this patch proposes maintaining a separate list
> > > > > for lazyfree anon folios while keeping them classified under the "file"
> > > > > LRU type to minimize code changes. These lazyfree anon folios
> > > > > will still be counted as file folios and share the same
> > > > > generation with regular files. In the eviction path, the
> > > > > lazyfree list will be prioritized for scanning before the actual file LRU list.
> > > > >
> > > >
> > > > What's the downside of another LRU list? Do we have any experience on
> that?
> > >
> > > Essentially, the goal is to address the downsides of using a single
> > > LRU list for files and lazyfree anonymous pages - seriously more files re-faults.
> > >
> > > I'm not entirely clear on the downsides of having an additional LRU
> > > list. While it does increase complexity, it doesn't seem to be significant.
> > >
> > > Let's wait for Gaoxu's test results before deciding on the next steps.
> > > I was just
> > > curious about how difficult it would be to add a separate list, so I
> > > took two hours to explore it :-)
> > Hi song,
> > I'm very sorry, various reasons combined have caused the delay in the results.
> >
> > Basic version：android V (enable Android ART use MADV_FREE) Test cases:
> > 60 apps repeatedly restarted, tested for 8 hours; The test results are
> > as follows:
> >         workingset_refault_anon   workingset_refault_file
> > base        42016805                92010542
> > patch       19834873                49383572
> > % diff       -52.79%                  -46.33%
> >
> > Additionally, a comparative test was conducted on
> > add-lazyfree-folio-to-lru-tail.patch[1], and the results are as follows:
> >                workingset_refault_anon   workingset_refault_file
> > lazyfree-tail        20313395                 52203061
> > patch             19834873                 49383572
> > % diff              -2.36%                    -5.40%
> >
> > From the results, it can be seen that this patch is very beneficial
> > and better than the results in [1]; it can solve the performance issue
> > of high IO caused by extensive use of MADV_FREE on the Android platform.
> >
> 
> Thank you for the testing and data. The results look promising. Would you mind
> if I send a v2 with the test data and your tag included in the changelog?
> I mean:
> 
> Tested-by: Gao Xu <gaoxu2@...onor.com>
Of course not, I'd be happy to.

Due to IO performance issues, Android has reverted the ART use of MADV_FREE;
it is expected that once the issue is resolved, Android ART will re-enable MADV_FREE 
and promote the use of MADV_FREE in more modules.
> 
> > Test case notes: There is a discrepancy between the test results
> > mentioned in [1] and the current test results because the test cases
> > are different. The test case used in [1] involves actions such as
> > clicking and swiping within the app after it starts; For the sake of
> > convenience and result stability, the current test case only involves
> > app startup without clicking and swiping, and the number of apps has been
> increased (30->60).
> >
> > 1.
> > https://lore.kernel.org/all/f29f64e29c08427b95e3df30a5770056@honor.com
> > /T/#u
> > >
> > > >
> > > > --
> > > > Cheers,
> > > >
> > > > David / dhildenb
> > > >
> > >
> 
> Thanks
> Barry

Powered by blists - more mailing lists