Re: Regression of madvise(MADV_COLD) on shmem?

[Ivan Teterevkov]

On 05-Mar-22 9:49 AM, Yu Zhao wrote:
> On Sat, Mar 5, 2022 at 2:17 AM Yu Zhao <yuzhao@xxxxxxxxxx> wrote:
> > On Fri, Mar 4, 2022 at 5:18 PM Minchan Kim <minchan@xxxxxxxxxx> wrote:
> > > On Fri, Mar 04, 2022 at 05:55:58PM +0000, Ivan Teterevkov wrote:
> > > > It makes me think there may be a regression in MADV_COLD. Please let me know
> > > > what do you reckon?
> > >
> > > Since deactive_page is called, I guess that's not a regression(?) from [1]
> > >
> > > Then, my random guess that you mentioned "Swap" as regression might be
> > > related to "workingset detection for anon page" since kernel changes balancing
> > > policy between file and anonymous LRU, which was merged into v5.8.
> > > It would be helpful to see if you try it on v5.7 and v5.8.
> > >
> > > [1] 12e967fd8e4e6, mm: do not allow MADV_PAGEOUT for CoW page
> >
> > Yes, I noticed this for a while. With commit b518154e59a ("mm/vmscan:
> > protect the workingset on anonymous LRU"), anon/shmem pages start on
> > the inactive lru, and in this case, deactive_page() is a NOP. Before
> > 5.9, anon/shmem pages start on the active lru, deactive_page() moves
> > zero pages in the test to the inactive lru and therefore protests the
> > "blob".
> >
> > This should fix the problem for your test case:

Thank you, it does fix the test case in 5.17.0-rc6+.

> > I'll leave it to Minchan to decide whether this is worth fixing,
> > together with this one:

I suppose add_page_to_lru_list_tail() makes madvise(MADV_COLD) more 
"insistent" with moving the pages at the end of the inactive LRU, but 
perhaps that's aligned with its purpose?

Cheers,
Ivan