Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
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.


  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