Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Lance Yang <lance.yang@linux.dev>
To: Mike Rapoport <rppt@kernel.org>
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 21:09:18 +0800	[thread overview]
Message-ID: <3ec76ffd-2650-4302-87e1-8183029a0553@linux.dev> (raw)
In-Reply-To: <aiAfnw088f3ZT3va@kernel.org>



On 2026/6/3 20:35, Mike Rapoport wrote:
> 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 :)

Yep. One x86 detail though, default seems to miss _PAGE_GLOBAL today. Not
sure if that is intentional or just historical. See patch #02.

>> 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.

And agreed, users should not care about the final mapping size, that is
up to the arch.

TBH, my concern is making the collapse cost implicit for every
set_direct_map_default_noflush() caller. I still lean toward keeping
it opt-in, but happy to hear what folks prefer :)

>   
>> [1] https://lore.kernel.org/linux-mm/9979fa87-88ef-4baf-8592-502ff4888085@kernel.org/
>>
>> Cheers, Lance
>>
> 


  reply	other threads:[~2026-06-03 13:09 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
2026-06-03 13:09         ` Lance Yang [this message]
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=3ec76ffd-2650-4302-87e1-8183029a0553@linux.dev \
    --to=lance.yang@linux.dev \
    --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=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rppt@kernel.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