> -----邮件原件----- > 发件人: Barry Song <21cnbao@xxxxxxxxx> > 发送时间: 2024年10月16日 4:10 > 收件人: gaoxu <gaoxu2@xxxxxxxxx> > 抄送: David Hildenbrand <david@xxxxxxxxxx>; akpm@xxxxxxxxxxxxxxxxxxxx; > linux-mm@xxxxxxxxx; mhocko@xxxxxxxx; hailong.liu@xxxxxxxx; > kaleshsingh@xxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > lokeshgidra@xxxxxxxxxx; ngeoffray@xxxxxxxxxx; shli@xxxxxx; > surenb@xxxxxxxxxx; yuzhao@xxxxxxxxxx; minchan@xxxxxxxxxx; Barry Song > <v-songbaohua@xxxxxxxx> > 主题: Re: [PATCH RFC] mm: mglru: provide a separate list for lazyfree anon folios > > On Tue, Oct 15, 2024 at 11:03 PM gaoxu <gaoxu2@xxxxxxxxx> wrote: > > > > > > > > On Wed, Sep 18, 2024 at 12:02 AM David Hildenbrand > > > <david@xxxxxxxxxx> > > > wrote: > > > > > > > > On 14.09.24 08:37, Barry Song wrote: > > > > > From: Barry Song <v-songbaohua@xxxxxxxx> > > > > > > > > > > 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@xxxxxxxxxxx> 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@xxxxxxxxx > > /T/#u > > > > > > > > > > > -- > > > > Cheers, > > > > > > > > David / dhildenb > > > > > > > > > Thanks > Barry
