All of lore.kernel.org
 help / color / mirror / Atom feed
From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: Barry Song <21cnbao@gmail.com>, Zi Yan <ziy@nvidia.com>,
	Tangquan Zheng <zhengtangquan@oppo.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, Barry Song <v-songbaohua@oppo.com>,
	David Hildenbrand <david@redhat.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Matthew Wilcox <willy@infradead.org>,
	Oscar Salvador <osalvador@suse.de>,
	Ryan Roberts <ryan.roberts@arm.com>
Subject: Re: [RFC PATCH] mm: don't promote exclusive file folios of dying processes
Date: Wed, 16 Apr 2025 16:24:15 +0800	[thread overview]
Message-ID: <76e951ec-5043-4e89-8a5f-efdeaec4bb81@linux.alibaba.com> (raw)
In-Reply-To: <CAGsJ_4yRq6iBPpWLdbcknGLGUCEBDsc05rAeMuK8HRAwnpg2Zg@mail.gmail.com>



On 2025/4/16 15:48, Barry Song wrote:
> On Sun, Apr 13, 2025 at 12:31 AM Zi Yan <ziy@nvidia.com> wrote:
>>
>> On 12 Apr 2025, at 4:58, Barry Song wrote:
>>
>>> From: Barry Song <v-songbaohua@oppo.com>
>>>
>>> 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 <baolin.wang@linux.alibaba.com>
>>> Cc: David Hildenbrand <david@redhat.com>
>>> Cc: Johannes Weiner <hannes@cmpxchg.org>
>>> Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
>>> Cc: Oscar Salvador <osalvador@suse.de>
>>> Cc: Ryan Roberts <ryan.roberts@arm.com>
>>> Cc: Zi Yan <ziy@nvidia.com>
>>> Signed-off-by: Barry Song <v-songbaohua@oppo.com>
>>> ---
>>>   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


  reply	other threads:[~2025-04-16  8:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-12  8:58 [RFC PATCH] mm: don't promote exclusive file folios of dying processes Barry Song
2025-04-12 15:48 ` Matthew Wilcox
2025-04-12 16:31 ` Zi Yan
2025-04-16  7:48   ` Barry Song
2025-04-16  8:24     ` Baolin Wang [this message]
2025-04-16  8:32 ` David Hildenbrand
2025-04-16  9:24   ` Barry Song
2025-04-16  9:32     ` David Hildenbrand
2025-04-16  9:38       ` Barry Song
2025-04-16  9:40         ` David Hildenbrand
2025-04-16 14:15           ` Johannes Weiner
2025-04-16 15:59             ` David Hildenbrand
2025-04-16 18:18               ` Johannes Weiner
2025-04-16 21:54                 ` Barry Song
2025-04-16 23:58                   ` Johannes Weiner
2025-04-17  2:43                     ` Barry Song
2025-04-17 12:17                       ` Johannes Weiner
2025-04-17 12:57                         ` David Hildenbrand
2025-04-18  0:16                           ` Barry Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=76e951ec-5043-4e89-8a5f-efdeaec4bb81@linux.alibaba.com \
    --to=baolin.wang@linux.alibaba.com \
    --cc=21cnbao@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=osalvador@suse.de \
    --cc=ryan.roberts@arm.com \
    --cc=v-songbaohua@oppo.com \
    --cc=willy@infradead.org \
    --cc=zhengtangquan@oppo.com \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.