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

[Minchan Kim <minchan@kernel.org>]

On Thu, Oct 17, 2024 at 06:59:09PM +1300, Barry Song wrote:
> On Thu, Oct 17, 2024 at 11:58 AM Andrew Morton
> <akpm@linux-foundation.org> wrote:
> >
> > On Wed, 16 Oct 2024 16:30:30 +1300 Barry Song <21cnbao@gmail.com> wrote:
> >
> > > 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.
> >
> > Thanks.  I'll await input from other MGLRU developers before adding
> > this for testing.
> 
> Thanks!
> 
> Hi Minchan, Yu,
> 
> Any comments? I understand that Minchan may have a broader plan
> to "enable the system to maintain a quickly reclaimable memory
> pool and provide a knob for admins to control its size." While I
> have no objection to that plan, I believe improving MADV_FREE
> performance is a more urgent priority and a low-hanging fruit at this
> stage.

Hi Barry, 

I have no idea why my email didn't send well before. I sent following
reply on Sep 24. Hope it works this time.

====== &< ======

My proposal involves the following:

1. Introduce an "easily reclaimable" LRU list. This list would hold pages
   that can be quickly freed without significant overhead.

2. Implement a parameter to control the size of this list. This allows for
   system tuning based on available memory and performance requirements.

3. Modify kswapd behavior to utilize this list. When kswapd is awakened due
   to memory pressure, it should attempt to drop those pages first to refill
   free pages up to the high watermark by first reclaiming.

4. Before kswapd goes to sleep, it should scan the tail of the LRU list and
   move cold pages to the easily reclaimable list, unmapping them from the
   page table.

5. Whenever page cache hit, move the page into evictable LRU.

This approach allows the system to maintain a pool of readily available
memory, mitigating the "aging" problem. The trade-off is the potential for
minor page faults and LRU movement ovehreads if these pages in ez_reclaimable
LRU are accessed again.

Furthermore, we could put some asynchrnous writeback pages(e.g., swap
out or writeback the fs pages) into the list, too.
Currently, what we are doing is rotate those pages back to head of LRU
and once writeback is done, move the page to the tail of LRU again.
We can simply put the page into ez_reclaimable LRU without rotating
back and forth.