From: "Yin, Fengwei" <fengwei.yin@intel.com>
To: David Hildenbrand <david@redhat.com>, Yu Zhao <yuzhao@google.com>,
Zi Yan <ziy@nvidia.com>
Cc: Minchan Kim <minchan@kernel.org>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>, <akpm@linux-foundation.org>,
<willy@infradead.org>, <ryan.roberts@arm.com>,
<shy828301@gmail.com>,
"Vishal Moola (Oracle)" <vishal.moola@gmail.com>
Subject: Re: [RFC PATCH] madvise: make madvise_cold_or_pageout_pte_range() support large folio
Date: Fri, 14 Jul 2023 21:58:15 +0800 [thread overview]
Message-ID: <9bcc8014-f5ef-9021-3ffc-032e39c32249@intel.com> (raw)
In-Reply-To: <36cfe140-5685-bea7-d267-4a61f21aeb79@redhat.com>
On 7/14/2023 5:25 PM, David Hildenbrand wrote:
>
> (1) We're unmapping a single subpage, the compound_mapcount == 0
> and the total_mapcount > 0. If the subpage mapcount is now 0, add it
> to the deferred split queue.
>
> (2) We're unmapping a complete folio (PMD mapping / compound), the
> compound_mapcount is 0 and the total_mapcount > 0.
>
> (a) If total mapcount < folio_nr_pages, add it
> to the deferred split queue.
>
> (b) If total mapcount >= folio_nr_pages , we have to scan all subpage
> mapcounts. If any subpage mapcount == 0, add it to the deferred
> split queue.
>
>
> (b) is a bit nasty. It would happen when we fork() with a PMD-mapped THP, the parent splits the THP due to COW, and then our child unmaps or splits the PMD-mapped THP (unmap easily happening during exec()). Fortunately, we'd only scan once when unmapping the PMD.
>
>
> Getting rid of the subpage mapcount usage in (1) would mean that we have to do exactly what we do in (2). But then we'd need to ha handle (2) (B) differently as well.
>
> So, for 2 (b) we would either need some other heuristic, or we add it to the deferred split queue more frequently and let that one detect using an rmap walk "well, every subpage is still mapped, let's abort the split".
Or another option for 2 (b): don't add it to deferred split queue. We
know the folio in deferred list is mainly scanned when system needs to
reclaim memory.
Maybe it's better to let page reclaim choose the large folio here because
page reclaiming will call folio_referenced() which does rmap_walk()->pvmw().
And we can reuse rmap_walk() in folio_referenced() to detect whether there
are pages of folio are not mapped. If it's the case, we can split it then.
Comparing to deferred list, the advantage is that folio_referenced() doesn't
unmap page. While in deferred list, we need to add extra rmap_walk() to
check whether there is page not mapped.
Just a thought. I could miss something here. Thanks.
Regards
Yin, Fengwei
next prev parent reply other threads:[~2023-07-14 13:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-13 15:05 [RFC PATCH] madvise: make madvise_cold_or_pageout_pte_range() support large folio Yin Fengwei
2023-07-14 2:08 ` Yu Zhao
2023-07-14 3:09 ` Yin, Fengwei
2023-07-14 3:23 ` Yu Zhao
2023-07-14 7:31 ` David Hildenbrand
2023-07-14 8:34 ` Yin, Fengwei
2023-07-14 9:25 ` David Hildenbrand
2023-07-14 13:58 ` Yin, Fengwei [this message]
2023-07-14 14:12 ` David Hildenbrand
2023-07-14 14:41 ` Zi Yan
2023-07-14 15:35 ` David Hildenbrand
2023-07-17 0:15 ` Yin, Fengwei
2023-07-17 14:38 ` Zi Yan
2023-07-17 23:38 ` Yin Fengwei
2023-07-14 3:57 ` Yu Zhao
2023-07-14 5:57 ` Yin, Fengwei
2023-07-14 15:41 ` Yu Zhao
2023-07-16 23:52 ` Yin, Fengwei
2023-07-17 16:29 ` Yu Zhao
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=9bcc8014-f5ef-9021-3ffc-032e39c32249@intel.com \
--to=fengwei.yin@intel.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=minchan@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=shy828301@gmail.com \
--cc=vishal.moola@gmail.com \
--cc=willy@infradead.org \
--cc=yuzhao@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).