Re: [RFC PATCH 1/2] mm/secretmem: try to restore large page mappings in direct map

[Lance Yang <lance.yang@linux.dev>]

On Wed, Jun 03, 2026 at 01:59:39PM +0300, Mike Rapoport wrote:
>Hi Lance,

Hey Mike,

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

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 :)

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

Cheers, Lance