On Wed, Aug 21, 2024 at 8:46 PM Michal Hocko <mhocko@xxxxxxxx> 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
