Re: Regression of madvise(MADV_COLD) on shmem?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux