From: David Hildenbrand <david@redhat.com>
To: Zi Yan <ziy@nvidia.com>, linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Yang Shi <shy828301@gmail.com>,
Ryan Roberts <ryan.roberts@arm.com>,
Barry Song <21cnbao@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/rmap: do not add fully unmapped large folio to deferred split list
Date: Thu, 11 Apr 2024 17:46:44 +0200 [thread overview]
Message-ID: <ffbbade3-2de5-4bbe-a6e4-49d2ff7a2f0e@redhat.com> (raw)
In-Reply-To: <20240411153232.169560-1-zi.yan@sent.com>
On 11.04.24 17:32, Zi Yan wrote:
> From: Zi Yan <ziy@nvidia.com>
>
> In __folio_remove_rmap(), a large folio is added to deferred split list
> if any page in a folio loses its final mapping. It is possible that
> the folio is unmapped fully, but it is unnecessary to add the folio
> to deferred split list at all. Fix it by checking folio mapcount before
> adding a folio to deferred split list.
>
> Signed-off-by: Zi Yan <ziy@nvidia.com>
> ---
> mm/rmap.c | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 2608c40dffad..d599a772e282 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -1494,7 +1494,7 @@ static __always_inline void __folio_remove_rmap(struct folio *folio,
> enum rmap_level level)
> {
> atomic_t *mapped = &folio->_nr_pages_mapped;
> - int last, nr = 0, nr_pmdmapped = 0;
> + int last, nr = 0, nr_pmdmapped = 0, mapcount = 0;
> enum node_stat_item idx;
>
> __folio_rmap_sanity_checks(folio, page, nr_pages, level);
> @@ -1506,7 +1506,8 @@ static __always_inline void __folio_remove_rmap(struct folio *folio,
> break;
> }
>
> - atomic_sub(nr_pages, &folio->_large_mapcount);
> + mapcount = atomic_sub_return(nr_pages,
> + &folio->_large_mapcount) + 1;
That becomes a new memory barrier on some archs. Rather just re-read it
below. Re-reading should be fine here.
> do {
> last = atomic_add_negative(-1, &page->_mapcount);
> if (last) {
> @@ -1554,7 +1555,9 @@ static __always_inline void __folio_remove_rmap(struct folio *folio,
> * is still mapped.
> */
> if (folio_test_large(folio) && folio_test_anon(folio))
> - if (level == RMAP_LEVEL_PTE || nr < nr_pmdmapped)
> + if ((level == RMAP_LEVEL_PTE &&
> + mapcount != 0) ||
> + (level == RMAP_LEVEL_PMD && nr < nr_pmdmapped))
> deferred_split_folio(folio);
> }
But I do wonder if we really care? Usually the folio will simply get
freed afterwards, where we simply remove it from the list.
If it's pinned, we won't be able to free or reclaim, but it's rather a
corner case ...
Is it really worth the added code? Not convinced.
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2024-04-11 15:46 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-11 15:32 Zi Yan
2024-04-11 15:46 ` David Hildenbrand [this message]
2024-04-11 19:01 ` Yang Shi
2024-04-11 21:15 ` David Hildenbrand
2024-04-11 21:59 ` Yang Shi
2024-04-12 14:21 ` Zi Yan
2024-04-12 14:31 ` Zi Yan
2024-04-12 18:29 ` Yang Shi
2024-04-12 19:36 ` David Hildenbrand
2024-04-12 20:21 ` Yang Shi
2024-04-12 19:06 ` David Hildenbrand
2024-04-12 14:35 ` Zi Yan
2024-04-12 19:32 ` David Hildenbrand
2024-04-12 20:35 ` Yang Shi
2024-04-15 15:43 ` David Hildenbrand
2024-04-12 21:06 ` Zi Yan
2024-04-12 22:29 ` Yang Shi
2024-04-12 22:59 ` Zi Yan
2024-04-13 0:50 ` Yang Shi
2024-04-15 15:40 ` David Hildenbrand
2024-04-15 17:54 ` Yang Shi
2024-04-15 19:19 ` David Hildenbrand
2024-04-15 21:16 ` Yang Shi
2024-04-15 15:13 ` David Hildenbrand
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=ffbbade3-2de5-4bbe-a6e4-49d2ff7a2f0e@redhat.com \
--to=david@redhat.com \
--cc=21cnbao@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ryan.roberts@arm.com \
--cc=shy828301@gmail.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