From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-189.mta0.migadu.com (out-189.mta0.migadu.com [91.218.175.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F064A3B2FEB for ; Wed, 3 Jun 2026 11:41:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.189 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780486913; cv=none; b=sZ6fK7MbqN594NQ1LJf+VfFQLC1YxmbZwrnUKV8GO3mjZgiq1GcyYxiutyc970vGVeNZw9qN9dJturB+v3TD6Pjd4Itgodz/MZbQRknRzXfcJKKwpBj6S1MOz6G1Xl6d1HoPV+G31opvyfO0c7VnunJ6ycvEPnGhp6L/Vor23YI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780486913; c=relaxed/simple; bh=7XAIE5do+IcADL1d5dImsNWM5s2T2yd85BhpI8NncBI=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=WXHfXgGcEF7y84p4k6HVTEJFxywF4+F0T7gFymxRI+loJCoHo9o82WdW+g130IovYRH3hCsjHx+uUKDD3ktx25/dlA+YzwaJlCrFlKxkiqOIT0sRSXStJhGlGfCRYsHsafqRq1jpnh7CRiDbRPdLwq1RrRytlJFcb9WcvnqfELc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=M4Wz5t/G; arc=none smtp.client-ip=91.218.175.189 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="M4Wz5t/G" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1780486908; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UL4u4uRmoBKLAhYy0Fqp9Y3r55rWdaL145K+bUKWQuc=; b=M4Wz5t/GibhfnNJucsvpMWybJ8N37f+NtPwNfqQbWUp/F2WviagIn1AYil01IjdZrdH1qZ KvJ02tTXvO8DRDlAUekPBpw55zsTAYV6lHYBRuG98UTQkk6MtthrQqBvLyNVCWplx6l9cx goCRkPNpH4YfnMx953wYvBWXY59ao1U= From: Lance Yang To: rppt@kernel.org Cc: lance.yang@linux.dev, 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 19:41:34 +0800 Message-Id: <20260603114134.3010-1-lance.yang@linux.dev> In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT 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 >> >> 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 >> Signed-off-by: Lance Yang >> --- >> 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