Re: [PATCH RFC] mm: mglru: provide a separate list for lazyfree anon folios

[Minchan Kim <minchan@kernel.org>]

On Fri, Sep 20, 2024 at 01:23:57PM +1200, Barry Song wrote:
> On Wed, Sep 18, 2024 at 12:02 AM David Hildenbrand <david@redhat.com> wrote:
> >
> > On 14.09.24 08:37, Barry Song wrote:
> > > From: Barry Song <v-songbaohua@oppo.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.

It's not a catastrophic[1]. I prefer the idea of an additional LRU
because it offers flexibility for various potential use cases[2].

orthgonal topic(but may be interest for someone)

My main interest in a new LRU list is to enable the system to maintain a
quickly reclaimable memory pool and expose the size to the admin with 
a knob to decide how many memory pool they want.

This pool would consist of clean, unmapped pages from both the page cache
and/or the swap cache. This would allow the system to reclaim memory quickly
when free memory is low, at the cost of minor fault overhead.

[1] https://lore.kernel.org/linux-kernel//1448006568-16031-15-git-send-email-minchan@kernel.org/
[2] https://lkml.org/lkml/2012/6/19/24