From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Dev Jain <dev.jain@arm.com>,
akpm@linux-foundation.org, ljs@kernel.org, muchun.song@linux.dev,
osalvador@suse.de
Cc: riel@surriel.com, liam@infradead.org, vbabka@kernel.org,
harry@kernel.org, jannh@google.com, lance.yang@linux.dev,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
ryan.roberts@arm.com, anshuman.khandual@arm.com
Subject: Re: [PATCH 4/5] mm/rmap: refactor anon swapbacked folio unmap in try_to_unmap_one
Date: Tue, 7 Jul 2026 16:26:03 +0200 [thread overview]
Message-ID: <1221180d-6217-401f-a479-3a5d9684659e@kernel.org> (raw)
In-Reply-To: <20260707121128.373192-5-dev.jain@arm.com>
On 7/7/26 14:11, Dev Jain wrote:
> Refactor anonymous swapbacked folio unmap to ttu_anon_swapbacked_folio().
>
> No functional change intended.
>
> Signed-off-by: Dev Jain <dev.jain@arm.com>
> ---
> mm/rmap.c | 105 ++++++++++++++++++++++++++++++++----------------------
> 1 file changed, 62 insertions(+), 43 deletions(-)
>
> diff --git a/mm/rmap.c b/mm/rmap.c
> index 00b571c2a1bab..ade78df5be2bd 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -2113,6 +2113,64 @@ static inline bool ttu_anon_lazyfree_folio(struct vm_area_struct *vma,
> return true;
> }
>
BTW, no need for the "inline" for most of these functions (applies to other
patches as well).
> +static inline void set_swp_pte_at(struct mm_struct *mm, unsigned long address,
> + pte_t *ptep, swp_entry_t entry, pte_t pteval, bool anon_exclusive)
It's confusing that we say "set_swp_pte_at", but the pte_t we was is actually
the old pte.
Can we instead have a function that creates us a swap_pte from the other data,
and then do the set_pte_at() in the caller?
static pte_t swp_pte_prepare(...)
{
...
return swp_pte;
}
> +{
> + pte_t swp_pte = swp_entry_to_pte(entry);
> +
> + if (anon_exclusive)
> + swp_pte = pte_swp_mkexclusive(swp_pte);
> +
> + if (likely(pte_present(pteval))) {
> + if (pte_soft_dirty(pteval))
> + swp_pte = pte_swp_mksoft_dirty(swp_pte);
> + if (pte_uffd_wp(pteval))
> + swp_pte = pte_swp_mkuffd_wp(swp_pte);
> + } else {
> + /* Device-exclusive entry */
> + if (pte_swp_soft_dirty(pteval))
> + swp_pte = pte_swp_mksoft_dirty(swp_pte);
> + if (pte_swp_uffd_wp(pteval))
> + swp_pte = pte_swp_mkuffd_wp(swp_pte);
> + }
> +
> + set_pte_at(mm, address, ptep, swp_pte);
> +}
> +
> +static inline bool ttu_anon_swapbacked_folio(struct vm_area_struct *vma, struct folio *folio,
> + struct page *subpage, unsigned long address, pte_t *ptep,
Subpages do not exist :)
> + pte_t pteval)
> +{
> + bool anon_exclusive = folio_test_anon(folio) && PageAnonExclusive(subpage);
const?
> + swp_entry_t entry = page_swap_entry(subpage);
> + struct mm_struct *mm = vma->vm_mm;
> +
> + if (folio_dup_swap(folio, subpage) < 0)
> + return false;
> +
> + /*
> + * arch_unmap_one() is expected to be a NOP on
> + * architectures where we could have PFN swap PTEs,
> + * so we'll not check/care.
> + */
> + if (arch_unmap_one(mm, vma, address, pteval) < 0) {
> + folio_put_swap(folio, subpage);
> + return false;
> + }
> +
> + /* See folio_try_share_anon_rmap(): clear PTE first. */
> + if (anon_exclusive && folio_try_share_anon_rmap_pte(folio, subpage)) {
> + folio_put_swap(folio, subpage);
I recall I stumbled over this before, but there is no way to undo the
arch_unmap_one(), right?
> + return false;
> + }
> +
> + mm_prepare_for_swap_entries(mm);
> + dec_mm_counter(mm, MM_ANONPAGES);
> + inc_mm_counter(mm, MM_SWAPENTS);
> + set_swp_pte_at(mm, address, ptep, entry, pteval, anon_exclusive);
> + return true;
> +}
> +
--
Cheers,
David
next prev parent reply other threads:[~2026-07-07 14:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-07 12:11 [PATCH 0/5] mm/rmap: Refactor try_to_unmap_one Dev Jain
2026-07-07 12:11 ` [PATCH 1/5] mm/rmap: convert page -> folio for hwpoison checks Dev Jain
2026-07-07 14:06 ` David Hildenbrand (Arm)
2026-07-07 12:11 ` [PATCH 2/5] mm/rmap: Add try_to_unmap_hugetlb_one Dev Jain
2026-07-07 14:15 ` David Hildenbrand (Arm)
2026-07-09 12:15 ` Dev Jain
2026-07-07 12:11 ` [PATCH 3/5] mm/rmap: refactor some code around lazyfree folio unmapping Dev Jain
2026-07-07 14:18 ` David Hildenbrand (Arm)
2026-07-09 12:16 ` Dev Jain
2026-07-09 13:43 ` David Hildenbrand (Arm)
2026-07-07 12:11 ` [PATCH 4/5] mm/rmap: refactor anon swapbacked folio unmap in try_to_unmap_one Dev Jain
2026-07-07 14:26 ` David Hildenbrand (Arm) [this message]
2026-07-09 13:39 ` Dev Jain
2026-07-07 12:11 ` [PATCH 5/5] mm/rmap: add anon folio unmap dispatcher function Dev Jain
2026-07-07 14:28 ` David Hildenbrand (Arm)
2026-07-09 13:34 ` Dev Jain
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=1221180d-6217-401f-a479-3a5d9684659e@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=dev.jain@arm.com \
--cc=harry@kernel.org \
--cc=jannh@google.com \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=riel@surriel.com \
--cc=ryan.roberts@arm.com \
--cc=vbabka@kernel.org \
/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.