From: Mike Rapoport <rppt@kernel.org>
To: Lance Yang <lance.yang@linux.dev>
Cc: akpm@linux-foundation.org, david@kernel.org, tglx@kernel.org,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
x86@kernel.org, hpa@zytor.com, luto@kernel.org,
peterz@infradead.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, xueyuan.chen21@gmail.com,
ioworker0@gmail.com
Subject: Re: [RFC PATCH 1/2] mm/secretmem: try to restore large page mappings in direct map
Date: Wed, 3 Jun 2026 15:35:43 +0300 [thread overview]
Message-ID: <aiAfnw088f3ZT3va@kernel.org> (raw)
In-Reply-To: <20260603114134.3010-1-lance.yang@linux.dev>
On Wed, Jun 03, 2026 at 07:41:34PM +0800, Lance Yang wrote:
> On Wed, Jun 03, 2026 at 01:59:39PM +0300, Mike Rapoport wrote:
> >On Wed, Jun 03, 2026 at 06:46:23PM +0800, Lance Yang wrote:
> >> From: Lance Yang <lance.yang@linux.dev>
> >>
> >> secretmem removes the pages backing secretmem mappings from the direct map.
> >>
> >> Removing one base page from the direct map can split the covering large
> >> mapping down to PTE mappings. Repeated splits can leave more of the direct
> >> map mapped with PTEs, meaning more TLB entries for the same range and
> >> potentially more TLB pressure.
> >>
> >> So let's try to restore large page mappings whenever secretmem restores a
> >> folio to the direct map.
> >>
> >> Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> >> Signed-off-by: Lance Yang <lance.yang@linux.dev>
> >> ---
> >> include/linux/set_memory.h | 6 ++++++
> >> mm/secretmem.c | 12 ++++++++++--
> >> 2 files changed, 16 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h
> >> index 3030d9245f5a..ad2fa414a22d 100644
> >> --- a/include/linux/set_memory.h
> >> +++ b/include/linux/set_memory.h
> >> @@ -58,6 +58,12 @@ static inline bool can_set_direct_map(void)
> >> #endif
> >> #endif /* CONFIG_ARCH_HAS_SET_DIRECT_MAP */
> >>
> >> +#ifndef arch_try_collapse_direct_map
> >> +static inline void arch_try_collapse_direct_map(struct page *page)
> >> +{
> >> +}
> >> +#endif
> >
> >Did you explore what would it mean to hook collapse_large_pages() into
> >set_direct_map_default_noflush()?
>
> Good point, I kept it separate on purpose :)
>
> Putting collapse into set_direct_map_default_noflush() would change the
> semantics of that helper a bit, IMHO.
For x86 default means present + rw + PSE, so yuu can look at it as actually
better enforcing the semantics :)
> I would expect arch_try_collapse_direct_map() to also be useful for cases
> where a direct-map permission change could split a large maping first,
> and the user wants to try restoring the large mapping after changing it
> back. One example[1] is making a direct-map range read-only for security,
> which I am also working on :)
I don't think users should care. The users care for particular permissions
of a range in the direct map. It should be up to the architecture to select
most suitable mapping size. The splits are implicit, I don't see why
collapses can't be implicit as well.
> [1] https://lore.kernel.org/linux-mm/9979fa87-88ef-4baf-8592-502ff4888085@kernel.org/
>
> Cheers, Lance
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2026-06-03 12:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-03 10:46 [RFC PATCH 0/2] restore large page mappings in direct map for secretmem Lance Yang
2026-06-03 10:46 ` [RFC PATCH 1/2] mm/secretmem: try to restore large page mappings in direct map Lance Yang
2026-06-03 10:59 ` Mike Rapoport
2026-06-03 11:41 ` Lance Yang
2026-06-03 12:35 ` Mike Rapoport [this message]
2026-06-03 13:09 ` Lance Yang
2026-06-03 15:48 ` David Hildenbrand (Arm)
2026-06-03 10:46 ` [RFC PATCH 2/2] x86/mm: restore large page mappings for secretmem Lance Yang
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=aiAfnw088f3ZT3va@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=hpa@zytor.com \
--cc=ioworker0@gmail.com \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=luto@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
--cc=xueyuan.chen21@gmail.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