From: Barry Song <21cnbao@gmail.com>
To: David Hildenbrand <david@redhat.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Barry Song <v-songbaohua@oppo.com>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Matthew Wilcox <willy@infradead.org>,
Oscar Salvador <osalvador@suse.de>,
Ryan Roberts <ryan.roberts@arm.com>, Zi Yan <ziy@nvidia.com>
Subject: Re: [RFC PATCH] mm: don't promote exclusive file folios of dying processes
Date: Wed, 16 Apr 2025 17:24:28 +0800 [thread overview]
Message-ID: <CAGsJ_4yUUK8LoejaUrXWscpPSQevq8jB4eFwpd6+Gw3T5JxdNg@mail.gmail.com> (raw)
In-Reply-To: <34c54df6-9a7c-475d-9b91-0f8acb118231@redhat.com>
On Wed, Apr 16, 2025 at 4:32 PM David Hildenbrand <david@redhat.com> wrote:
>
> On 12.04.25 10: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.
>
> 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
next prev parent reply other threads:[~2025-04-16 9:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-12 8:58 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
2025-04-16 8:32 ` David Hildenbrand
2025-04-16 9:24 ` Barry Song [this message]
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=CAGsJ_4yUUK8LoejaUrXWscpPSQevq8jB4eFwpd6+Gw3T5JxdNg@mail.gmail.com \
--to=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=baolin.wang@linux.alibaba.com \
--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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox