linux-kernel - Re: [PATCH v2] mm: add lazyfree folio to lru tail

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGsJ_4zgQ0MBV-yucc0-7BcDgjMMdCUDWK330mrd7SS4ej6Q8Q@mail.gmail.com>
Date: Thu, 22 Aug 2024 05:47:34 +0800
From: Barry Song <21cnbao@...il.com>
To: Michal Hocko <mhocko@...e.com>
Cc: gaoxu <gaoxu2@...or.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	"linux-mm@...ck.org" <linux-mm@...ck.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Suren Baghdasaryan <surenb@...gle.com>, 
	Shaohua Li <shli@...com>, yipengxiang <yipengxiang@...or.com>, fengbaopeng <fengbaopeng@...or.com>, 
	Kalesh Singh <kaleshsingh@...gle.com>
Subject: Re: [PATCH v2] mm: add lazyfree folio to lru tail

On Wed, Aug 21, 2024 at 8:46 PM Michal Hocko <mhocko@...e.com> wrote:
>
> On Fri 16-08-24 07:48:01, gaoxu wrote:
> > Replace lruvec_add_folio with lruvec_add_folio_tail in the lru_lazyfree_fn:
> > 1. The lazy-free folio is added to the LRU_INACTIVE_FILE list. If it's
> >    moved to the LRU tail, it allows for faster release lazy-free folio and
> >    reduces the impact on file refault.
>
> This has been discussed when MADV_FREE was introduced. The question was
> whether this memory has a lower priority than other inactive memory that
> has been marked that way longer ago. Also consider several MADV_FREE
> users should they be LIFO from the reclaim POV?

The priority of this memory compared to other inactive memory that has been
marked for a longer time likely depends on the user's expectations - How soon
do users expect MADV_FREE to be reclaimed compared with old file folios.

art guys moved to MADV_FREE from MADV_DONTNEED without any
useful performance data and reason in the changelog:
https://android-review.googlesource.com/c/platform/art/+/2633132

Since art is the Android Java heap, it can be quite large. This increases the
likelihood of packing the file LRU and reduces the chances of reclaiming
anonymous memory, which could result in more file re-faults while helping
anonymous folio persist longer in memory.

I am really curious why art guys have moved to MADV_FREE if we have
an approach to reach them.

>
> --
> Michal Hocko
> SUSE Labs
>

Thanks
Barry