[RFC] mm: don't promote exclusive file folios of dying processes

Commit Message

Barry Song April 12, 2025, 8:58 a.m. UTC

From: Barry Song <[e-mail]>

Promoting exclusive file folios of a dying process is unnecessary and
harmful. For example, while Firefox is killed and LibreOffice is
launched, activating Firefox's young file-backed folios makes it
harder to reclaim memory that LibreOffice doesn't use at all.

An exiting process is unlikely to be restarted right away—it's
either terminated by the user or killed by the OOM handler.

Cc: Baolin Wang <[e-mail]>
Cc: David Hildenbrand <[e-mail]>
Cc: Johannes Weiner <[e-mail]>
Cc: Matthew Wilcox (Oracle) <[e-mail]>
Cc: Oscar Salvador <[e-mail]>
Cc: Ryan Roberts <[e-mail]>
Cc: Zi Yan <[e-mail]>
Signed-off-by: Barry Song <[e-mail]>
---
 mm/huge_memory.c |  4 ++--
 mm/internal.h    | 19 +++++++++++++++++++
 mm/memory.c      |  9 ++++++++-
 3 files changed, 29 insertions(+), 3 deletions(-)

Comments

Matthew Wilcox April 12, 2025, 3:48 p.m. UTC | #1

On Sat, Apr 12, 2025 at 08:58:52PM +1200, Barry Song wrote:
> +		/*
> +		 * Skip marking exclusive file folios as accessed for processes that are
> +		 * exiting or have been reaped due to OOM. This prevents unnecessary
> +		 * promotion of folios that won't benefit the new process being launched.
> +		 */

Please wrap at 80 columns.

One easy way to achieve this is to pipe it through 'fmt -p \*'

Zi Yan April 12, 2025, 4:31 p.m. UTC | #2

On 12 Apr 2025, at 4:58, Barry Song wrote:

> From: Barry Song <[e-mail]>
>
> Promoting exclusive file folios of a dying process is unnecessary and
> harmful. For example, while Firefox is killed and LibreOffice is
> launched, activating Firefox's young file-backed folios makes it
> harder to reclaim memory that LibreOffice doesn't use at all.
>
> An exiting process is unlikely to be restarted right away—it's
> either terminated by the user or killed by the OOM handler.

The proposal looks reasonable to me. Do you have any performance number
about the improvement?

>
> Cc: Baolin Wang <[e-mail]>
> Cc: David Hildenbrand <[e-mail]>
> Cc: Johannes Weiner <[e-mail]>
> Cc: Matthew Wilcox (Oracle) <[e-mail]>
> Cc: Oscar Salvador <[e-mail]>
> Cc: Ryan Roberts <[e-mail]>
> Cc: Zi Yan <[e-mail]>
> Signed-off-by: Barry Song <[e-mail]>
> ---
>  mm/huge_memory.c |  4 ++--
>  mm/internal.h    | 19 +++++++++++++++++++
>  mm/memory.c      |  9 ++++++++-
>  3 files changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index e97a97586478..05b83d2fcbb6 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -2264,8 +2264,8 @@ int zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
>  			 * Use flush_needed to indicate whether the PMD entry
>  			 * is present, instead of checking pmd_present() again.
>  			 */
> -			if (flush_needed && pmd_young(orig_pmd) &&
> -			    likely(vma_has_recency(vma)))
> +			if (!exclusive_folio_of_dying_process(folio, vma) && flush_needed &&
> +			    pmd_young(orig_pmd) && likely(vma_has_recency(vma)))
>  				folio_mark_accessed(folio);
>  		}
>
> diff --git a/mm/internal.h b/mm/internal.h
> index 4e0ea83aaf1c..666de96a293d 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -11,6 +11,7 @@
>  #include <linux/khugepaged.h>
>  #include <linux/mm.h>
>  #include <linux/mm_inline.h>
> +#include <linux/oom.h>
>  #include <linux/pagemap.h>
>  #include <linux/pagewalk.h>
>  #include <linux/rmap.h>
> @@ -130,6 +131,24 @@ static inline int folio_nr_pages_mapped(const struct folio *folio)
>  	return atomic_read(&folio->_nr_pages_mapped) & FOLIO_PAGES_MAPPED;
>  }
>
> +/*
> + * Return true if a folio is exclusive and belongs to an exiting or
> + * oom-reaped process; otherwise, return false.
> + */
> +static inline bool exclusive_folio_of_dying_process(struct folio *folio,
> +		struct vm_area_struct *vma)
> +{
> +	if (folio_maybe_mapped_shared(folio))
> +		return false;
> +
> +	if (!atomic_read(&vma->vm_mm->mm_users))
> +		return true;
> +	if (check_stable_address_space(vma->vm_mm))
> +		return true;
> +
> +	return false;
> +}
> +
>  /*
>   * Retrieve the first entry of a folio based on a provided entry within the
>   * folio. We cannot rely on folio->swap as there is no guarantee that it has
> diff --git a/mm/memory.c b/mm/memory.c
> index b9e8443aaa86..cab69275e473 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1515,7 +1515,14 @@ static __always_inline void zap_present_folio_ptes(struct mmu_gather *tlb,
>  				*force_flush = true;
>  			}
>  		}
> -		if (pte_young(ptent) && likely(vma_has_recency(vma)))
> +
> +		/*
> +		 * Skip marking exclusive file folios as accessed for processes that are
> +		 * exiting or have been reaped due to OOM. This prevents unnecessary
> +		 * promotion of folios that won't benefit the new process being launched.
> +		 */
> +		if (!exclusive_folio_of_dying_process(folio, vma) && pte_young(ptent) &&
> +				likely(vma_has_recency(vma)))
>  			folio_mark_accessed(folio);
>  		rss[mm_counter(folio)] -= nr;
>  	} else {
> -- 
> 2.39.3 (Apple Git-146)


--
Best Regards,
Yan, Zi

Barry Song April 16, 2025, 7:48 a.m. UTC | #3

On Sun, Apr 13, 2025 at 12:31 AM Zi Yan <[e-mail]> wrote:
>
> On 12 Apr 2025, at 4:58, Barry Song wrote:
>
> > From: Barry Song <[e-mail]>
> >
> > Promoting exclusive file folios of a dying process is unnecessary and
> > harmful. For example, while Firefox is killed and LibreOffice is
> > launched, activating Firefox's young file-backed folios makes it
> > harder to reclaim memory that LibreOffice doesn't use at all.
> >
> > An exiting process is unlikely to be restarted right away—it's
> > either terminated by the user or killed by the OOM handler.
>
> The proposal looks reasonable to me. Do you have any performance number
> about the improvement?

Tangquan ran the test on Android phones and saw 3% improvement on
refault/thrashing things:
                                                   w/o patch           w/patch
workingset_refault_anon    2215933          2146602            3.13%
workingset_refault_file       9859208          9646518             2.16%
pswpin                                2411086          2337790             3.04%
pswpout                              6482838          6264865             3.36%

A further demotion of exclusive file folios can improvement more, but
might be controversial. it could be a separate patch later.

>
> >
> > Cc: Baolin Wang <[e-mail]>
> > Cc: David Hildenbrand <[e-mail]>
> > Cc: Johannes Weiner <[e-mail]>
> > Cc: Matthew Wilcox (Oracle) <[e-mail]>
> > Cc: Oscar Salvador <[e-mail]>
> > Cc: Ryan Roberts <[e-mail]>
> > Cc: Zi Yan <[e-mail]>
> > Signed-off-by: Barry Song <[e-mail]>
> > ---
> >  mm/huge_memory.c |  4 ++--
> >  mm/internal.h    | 19 +++++++++++++++++++
> >  mm/memory.c      |  9 ++++++++-
> >  3 files changed, 29 insertions(+), 3 deletions(-)
> >
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index e97a97586478..05b83d2fcbb6 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -2264,8 +2264,8 @@ int zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
> >                        * Use flush_needed to indicate whether the PMD entry
> >                        * is present, instead of checking pmd_present() again.
> >                        */
> > -                     if (flush_needed && pmd_young(orig_pmd) &&
> > -                         likely(vma_has_recency(vma)))
> > +                     if (!exclusive_folio_of_dying_process(folio, vma) && flush_needed &&
> > +                         pmd_young(orig_pmd) && likely(vma_has_recency(vma)))
> >                               folio_mark_accessed(folio);
> >               }
> >
> > diff --git a/mm/internal.h b/mm/internal.h
> > index 4e0ea83aaf1c..666de96a293d 100644
> > --- a/mm/internal.h
> > +++ b/mm/internal.h
> > @@ -11,6 +11,7 @@
> >  #include <linux/khugepaged.h>
> >  #include <linux/mm.h>
> >  #include <linux/mm_inline.h>
> > +#include <linux/oom.h>
> >  #include <linux/pagemap.h>
> >  #include <linux/pagewalk.h>
> >  #include <linux/rmap.h>
> > @@ -130,6 +131,24 @@ static inline int folio_nr_pages_mapped(const struct folio *folio)
> >       return atomic_read(&folio->_nr_pages_mapped) & FOLIO_PAGES_MAPPED;
> >  }
> >
> > +/*
> > + * Return true if a folio is exclusive and belongs to an exiting or
> > + * oom-reaped process; otherwise, return false.
> > + */
> > +static inline bool exclusive_folio_of_dying_process(struct folio *folio,
> > +             struct vm_area_struct *vma)
> > +{
> > +     if (folio_maybe_mapped_shared(folio))
> > +             return false;
> > +
> > +     if (!atomic_read(&vma->vm_mm->mm_users))
> > +             return true;
> > +     if (check_stable_address_space(vma->vm_mm))
> > +             return true;
> > +
> > +     return false;
> > +}
> > +
> >  /*
> >   * Retrieve the first entry of a folio based on a provided entry within the
> >   * folio. We cannot rely on folio->swap as there is no guarantee that it has
> > diff --git a/mm/memory.c b/mm/memory.c
> > index b9e8443aaa86..cab69275e473 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -1515,7 +1515,14 @@ static __always_inline void zap_present_folio_ptes(struct mmu_gather *tlb,
> >                               *force_flush = true;
> >                       }
> >               }
> > -             if (pte_young(ptent) && likely(vma_has_recency(vma)))
> > +
> > +             /*
> > +              * Skip marking exclusive file folios as accessed for processes that are
> > +              * exiting or have been reaped due to OOM. This prevents unnecessary
> > +              * promotion of folios that won't benefit the new process being launched.
> > +              */
> > +             if (!exclusive_folio_of_dying_process(folio, vma) && pte_young(ptent) &&
> > +                             likely(vma_has_recency(vma)))
> >                       folio_mark_accessed(folio);
> >               rss[mm_counter(folio)] -= nr;
> >       } else {
> > --
> > 2.39.3 (Apple Git-146)
>
>
> --
> Best Regards,
> Yan, Zi

Thanks
Barry

Baolin Wang April 16, 2025, 8:24 a.m. UTC | #4

On 2025/4/16 15:48, Barry Song wrote:
> On Sun, Apr 13, 2025 at 12:31 AM Zi Yan <[e-mail]> wrote:
>>
>> On 12 Apr 2025, at 4:58, Barry Song wrote:
>>
>>> From: Barry Song <[e-mail]>
>>>
>>> Promoting exclusive file folios of a dying process is unnecessary and
>>> harmful. For example, while Firefox is killed and LibreOffice is
>>> launched, activating Firefox's young file-backed folios makes it
>>> harder to reclaim memory that LibreOffice doesn't use at all.
>>>
>>> An exiting process is unlikely to be restarted right away—it's
>>> either terminated by the user or killed by the OOM handler.
>>
>> The proposal looks reasonable to me. Do you have any performance number
>> about the improvement?
> 
> Tangquan ran the test on Android phones and saw 3% improvement on
> refault/thrashing things:

Good.

>                                                     w/o patch           w/patch
> workingset_refault_anon    2215933          2146602            3.13%
> workingset_refault_file       9859208          9646518             2.16%
> pswpin                                2411086          2337790             3.04%
> pswpout                              6482838          6264865             3.36%
> 
> A further demotion of exclusive file folios can improvement more, but
> might be controversial. it could be a separate patch later.
> 
>>
>>>
>>> Cc: Baolin Wang <[e-mail]>
>>> Cc: David Hildenbrand <[e-mail]>
>>> Cc: Johannes Weiner <[e-mail]>
>>> Cc: Matthew Wilcox (Oracle) <[e-mail]>
>>> Cc: Oscar Salvador <[e-mail]>
>>> Cc: Ryan Roberts <[e-mail]>
>>> Cc: Zi Yan <[e-mail]>
>>> Signed-off-by: Barry Song <[e-mail]>
>>> ---
>>>   mm/huge_memory.c |  4 ++--
>>>   mm/internal.h    | 19 +++++++++++++++++++
>>>   mm/memory.c      |  9 ++++++++-
>>>   3 files changed, 29 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
>>> index e97a97586478..05b83d2fcbb6 100644
>>> --- a/mm/huge_memory.c
>>> +++ b/mm/huge_memory.c
>>> @@ -2264,8 +2264,8 @@ int zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
>>>                         * Use flush_needed to indicate whether the PMD entry
>>>                         * is present, instead of checking pmd_present() again.
>>>                         */
>>> -                     if (flush_needed && pmd_young(orig_pmd) &&
>>> -                         likely(vma_has_recency(vma)))
>>> +                     if (!exclusive_folio_of_dying_process(folio, vma) && flush_needed &&

Nit: I prefer to check 'flush_needed' first to make sure it is a present 
pte. Otherwise look good to me.

>>> +                         pmd_young(orig_pmd) && likely(vma_has_recency(vma)))
>>>                                folio_mark_accessed(folio);
>>>                }
>>>
>>> diff --git a/mm/internal.h b/mm/internal.h
>>> index 4e0ea83aaf1c..666de96a293d 100644
>>> --- a/mm/internal.h
>>> +++ b/mm/internal.h
>>> @@ -11,6 +11,7 @@
>>>   #include <linux/khugepaged.h>
>>>   #include <linux/mm.h>
>>>   #include <linux/mm_inline.h>
>>> +#include <linux/oom.h>
>>>   #include <linux/pagemap.h>
>>>   #include <linux/pagewalk.h>
>>>   #include <linux/rmap.h>
>>> @@ -130,6 +131,24 @@ static inline int folio_nr_pages_mapped(const struct folio *folio)
>>>        return atomic_read(&folio->_nr_pages_mapped) & FOLIO_PAGES_MAPPED;
>>>   }
>>>
>>> +/*
>>> + * Return true if a folio is exclusive and belongs to an exiting or
>>> + * oom-reaped process; otherwise, return false.
>>> + */
>>> +static inline bool exclusive_folio_of_dying_process(struct folio *folio,
>>> +             struct vm_area_struct *vma)
>>> +{
>>> +     if (folio_maybe_mapped_shared(folio))
>>> +             return false;
>>> +
>>> +     if (!atomic_read(&vma->vm_mm->mm_users))
>>> +             return true;
>>> +     if (check_stable_address_space(vma->vm_mm))
>>> +             return true;
>>> +
>>> +     return false;
>>> +}
>>> +
>>>   /*
>>>    * Retrieve the first entry of a folio based on a provided entry within the
>>>    * folio. We cannot rely on folio->swap as there is no guarantee that it has
>>> diff --git a/mm/memory.c b/mm/memory.c
>>> index b9e8443aaa86..cab69275e473 100644
>>> --- a/mm/memory.c
>>> +++ b/mm/memory.c
>>> @@ -1515,7 +1515,14 @@ static __always_inline void zap_present_folio_ptes(struct mmu_gather *tlb,
>>>                                *force_flush = true;
>>>                        }
>>>                }
>>> -             if (pte_young(ptent) && likely(vma_has_recency(vma)))
>>> +
>>> +             /*
>>> +              * Skip marking exclusive file folios as accessed for processes that are
>>> +              * exiting or have been reaped due to OOM. This prevents unnecessary
>>> +              * promotion of folios that won't benefit the new process being launched.
>>> +              */
>>> +             if (!exclusive_folio_of_dying_process(folio, vma) && pte_young(ptent) &&
>>> +                             likely(vma_has_recency(vma)))
>>>                        folio_mark_accessed(folio);
>>>                rss[mm_counter(folio)] -= nr;
>>>        } else {
>>> --
>>> 2.39.3 (Apple Git-146)
>>
>>
>> --
>> Best Regards,
>> Yan, Zi
> 
> Thanks
> Barry

David Hildenbrand April 16, 2025, 8:32 a.m. UTC | #5

On 12.04.25 10:58, Barry Song wrote:
> From: Barry Song <[e-mail]>
> 
> Promoting exclusive file folios of a dying process is unnecessary and
> harmful. For example, while Firefox is killed and LibreOffice is
> launched, activating Firefox's young file-backed folios makes it
> harder to reclaim memory that LibreOffice doesn't use at all.

Do we know when it is reasonable to promote any folios of a dying process?

Assume you restart Firefox, would it really matter to promote them when 
unmapping? New Firefox would fault-in / touch the ones it really needs 
immediately afterwards?

Barry Song April 16, 2025, 9:24 a.m. UTC | #6

On Wed, Apr 16, 2025 at 4:32 PM David Hildenbrand <[e-mail]> wrote:
>
> On 12.04.25 10:58, Barry Song wrote:
> > From: Barry Song <[e-mail]>
> >
> > Promoting exclusive file folios of a dying process is unnecessary and
> > harmful. For example, while Firefox is killed and LibreOffice is
> > launched, activating Firefox's young file-backed folios makes it
> > harder to reclaim memory that LibreOffice doesn't use at all.
>
> Do we know when it is reasonable to promote any folios of a dying process?
>

I don't know. It seems not reasonable at all. if one service crashes due to
SW bug, systemd will restart it immediately. this might be the case promoting
folios might be good. but it is really a bug of the service, not a normal case.

> Assume you restart Firefox, would it really matter to promote them when
> unmapping? New Firefox would fault-in / touch the ones it really needs
> immediately afterwards?

Usually users kill firefox to start other applications (users intend
to free memory
for new applications). For Android, an app might be killed because it has been
staying in the background inactively for a while.

On the other hand, even if users restart firefox immediately, their folios are
probably still in LRU to hit.

>
> --
> Cheers,
>
> David / dhildenb
>
Thanks
Barry

David Hildenbrand April 16, 2025, 9:32 a.m. UTC | #7

On 16.04.25 11:24, Barry Song wrote:
> On Wed, Apr 16, 2025 at 4:32 PM David Hildenbrand <[e-mail]> wrote:
>>
>> On 12.04.25 10:58, Barry Song wrote:
>>> From: Barry Song <[e-mail]>
>>>
>>> Promoting exclusive file folios of a dying process is unnecessary and
>>> harmful. For example, while Firefox is killed and LibreOffice is
>>> launched, activating Firefox's young file-backed folios makes it
>>> harder to reclaim memory that LibreOffice doesn't use at all.
>>
>> Do we know when it is reasonable to promote any folios of a dying process?
>>
> 
> I don't know. It seems not reasonable at all. if one service crashes due to
> SW bug, systemd will restart it immediately. this might be the case promoting
> folios might be good. but it is really a bug of the service, not a normal case.
> 
>> Assume you restart Firefox, would it really matter to promote them when
>> unmapping? New Firefox would fault-in / touch the ones it really needs
>> immediately afterwards?
> 
> Usually users kill firefox to start other applications (users intend
> to free memory
> for new applications). For Android, an app might be killed because it has been
> staying in the background inactively for a while.

> On the other hand, even if users restart firefox immediately, their folios are
> probably still in LRU to hit.

Right, that's what I'm thinking.

So I wonder if we could just say "the whole process is going down; even 
if we had some recency information, that could only affect some other 
process, where we would have to guess if it really matters".

If the data is important, one would assume that another process would 
soon access it either way, and as you say, likely it will still be on 
the LRU to hit.

Barry Song April 16, 2025, 9:38 a.m. UTC | #8

On Wed, Apr 16, 2025 at 5:32 PM David Hildenbrand <[e-mail]> wrote:
>
> On 16.04.25 11:24, Barry Song wrote:
> > On Wed, Apr 16, 2025 at 4:32 PM David Hildenbrand <[e-mail]> wrote:
> >>
> >> On 12.04.25 10:58, Barry Song wrote:
> >>> From: Barry Song <[e-mail]>
> >>>
> >>> Promoting exclusive file folios of a dying process is unnecessary and
> >>> harmful. For example, while Firefox is killed and LibreOffice is
> >>> launched, activating Firefox's young file-backed folios makes it
> >>> harder to reclaim memory that LibreOffice doesn't use at all.
> >>
> >> Do we know when it is reasonable to promote any folios of a dying process?
> >>
> >
> > I don't know. It seems not reasonable at all. if one service crashes due to
> > SW bug, systemd will restart it immediately. this might be the case promoting
> > folios might be good. but it is really a bug of the service, not a normal case.
> >
> >> Assume you restart Firefox, would it really matter to promote them when
> >> unmapping? New Firefox would fault-in / touch the ones it really needs
> >> immediately afterwards?
> >
> > Usually users kill firefox to start other applications (users intend
> > to free memory
> > for new applications). For Android, an app might be killed because it has been
> > staying in the background inactively for a while.
>
> > On the other hand, even if users restart firefox immediately, their folios are
> > probably still in LRU to hit.
>
> Right, that's what I'm thinking.
>
> So I wonder if we could just say "the whole process is going down; even
> if we had some recency information, that could only affect some other
> process, where we would have to guess if it really matters".
>
> If the data is important, one would assume that another process would
> soon access it either way, and as you say, likely it will still be on
> the LRU to hit.

I'll include this additional information in the v2 version of the patch since
you think it would be helpful.

Regarding the exclusive flag - I'm wondering whether we actually need to
distinguish between exclusive and shared folios in this case. The current
patch uses the exclusive flag mainly to reduce controversy, but even for
shared folios: does the recency from a dying process matter? The
recency information only reflects the dying process's usage pattern, which
will soon be irrelevant.

>
> --
> Cheers,
>
> David / dhildenb
>

Thanks
Barry

David Hildenbrand April 16, 2025, 9:40 a.m. UTC | #9

On 16.04.25 11:38, Barry Song wrote:
> On Wed, Apr 16, 2025 at 5:32 PM David Hildenbrand <[e-mail]> wrote:
>>
>> On 16.04.25 11:24, Barry Song wrote:
>>> On Wed, Apr 16, 2025 at 4:32 PM David Hildenbrand <[e-mail]> wrote:
>>>>
>>>> On 12.04.25 10:58, Barry Song wrote:
>>>>> From: Barry Song <[e-mail]>
>>>>>
>>>>> Promoting exclusive file folios of a dying process is unnecessary and
>>>>> harmful. For example, while Firefox is killed and LibreOffice is
>>>>> launched, activating Firefox's young file-backed folios makes it
>>>>> harder to reclaim memory that LibreOffice doesn't use at all.
>>>>
>>>> Do we know when it is reasonable to promote any folios of a dying process?
>>>>
>>>
>>> I don't know. It seems not reasonable at all. if one service crashes due to
>>> SW bug, systemd will restart it immediately. this might be the case promoting
>>> folios might be good. but it is really a bug of the service, not a normal case.
>>>
>>>> Assume you restart Firefox, would it really matter to promote them when
>>>> unmapping? New Firefox would fault-in / touch the ones it really needs
>>>> immediately afterwards?
>>>
>>> Usually users kill firefox to start other applications (users intend
>>> to free memory
>>> for new applications). For Android, an app might be killed because it has been
>>> staying in the background inactively for a while.
>>
>>> On the other hand, even if users restart firefox immediately, their folios are
>>> probably still in LRU to hit.
>>
>> Right, that's what I'm thinking.
>>
>> So I wonder if we could just say "the whole process is going down; even
>> if we had some recency information, that could only affect some other
>> process, where we would have to guess if it really matters".
>>
>> If the data is important, one would assume that another process would
>> soon access it either way, and as you say, likely it will still be on
>> the LRU to hit.
> 
> I'll include this additional information in the v2 version of the patch since
> you think it would be helpful.
> 
> Regarding the exclusive flag - I'm wondering whether we actually need to
> distinguish between exclusive and shared folios in this case. The current
> patch uses the exclusive flag mainly to reduce controversy, but even for
> shared folios: does the recency from a dying process matter? The
> recency information only reflects the dying process's usage pattern, which
> will soon be irrelevant.

Exactly my thoughts. So if we can simplify -- ignore it completely -- 
that would certainly be nice.

Patch

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index e97a97586478..05b83d2fcbb6 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2264,8 +2264,8 @@  int zap_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
 			 * Use flush_needed to indicate whether the PMD entry
 			 * is present, instead of checking pmd_present() again.
 			 */
-			if (flush_needed && pmd_young(orig_pmd) &&
-			    likely(vma_has_recency(vma)))
+			if (!exclusive_folio_of_dying_process(folio, vma) && flush_needed &&
+			    pmd_young(orig_pmd) && likely(vma_has_recency(vma)))
 				folio_mark_accessed(folio);
 		}
 
diff --git a/mm/internal.h b/mm/internal.h
index 4e0ea83aaf1c..666de96a293d 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -11,6 +11,7 @@ 
 #include <linux/khugepaged.h>
 #include <linux/mm.h>
 #include <linux/mm_inline.h>
+#include <linux/oom.h>
 #include <linux/pagemap.h>
 #include <linux/pagewalk.h>
 #include <linux/rmap.h>
@@ -130,6 +131,24 @@  static inline int folio_nr_pages_mapped(const struct folio *folio)
 	return atomic_read(&folio->_nr_pages_mapped) & FOLIO_PAGES_MAPPED;
 }
 
+/*
+ * Return true if a folio is exclusive and belongs to an exiting or
+ * oom-reaped process; otherwise, return false.
+ */
+static inline bool exclusive_folio_of_dying_process(struct folio *folio,
+		struct vm_area_struct *vma)
+{
+	if (folio_maybe_mapped_shared(folio))
+		return false;
+
+	if (!atomic_read(&vma->vm_mm->mm_users))
+		return true;
+	if (check_stable_address_space(vma->vm_mm))
+		return true;
+
+	return false;
+}
+
 /*
  * Retrieve the first entry of a folio based on a provided entry within the
  * folio. We cannot rely on folio->swap as there is no guarantee that it has
diff --git a/mm/memory.c b/mm/memory.c
index b9e8443aaa86..cab69275e473 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1515,7 +1515,14 @@  static __always_inline void zap_present_folio_ptes(struct mmu_gather *tlb,
 				*force_flush = true;
 			}
 		}
-		if (pte_young(ptent) && likely(vma_has_recency(vma)))
+
+		/*
+		 * Skip marking exclusive file folios as accessed for processes that are
+		 * exiting or have been reaped due to OOM. This prevents unnecessary
+		 * promotion of folios that won't benefit the new process being launched.
+		 */
+		if (!exclusive_folio_of_dying_process(folio, vma) && pte_young(ptent) &&
+				likely(vma_has_recency(vma)))
 			folio_mark_accessed(folio);
 		rss[mm_counter(folio)] -= nr;
 	} else {