From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-182.mta0.migadu.com (out-182.mta0.migadu.com [91.218.175.182]) (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 91B7B376A19 for ; Wed, 3 Jun 2026 13:09:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780492172; cv=none; b=Uz1fkTHON7AaBXVaIUsoARWoLGbbIiZlzxLE26F4EWgvhx9zUBfTKWSri+Tuxf+tGhRJ6qglVrrU4IqXynA0dZb3bhhABkE61oii83RQWOQeCO5L8TP+O2aPLJmpGGgIcdOozNYSDMW71H6lf+daxGCJmrtcsxnu1+fCmeWGdJ0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780492172; c=relaxed/simple; bh=xuV66FXVDqrpvx3pYM+lFkmQuoZkgRrKT+ecvdzSW2s=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=o89QT0Dl9L4E9ezuUEraw+wizKvlEa7GXkKBlhz6TaKTyf9G49qXQLbU+o4vMlsOpJ2lBi/kuDXf5d7uzD2JZR4Qyw+Fg/k7RYXYMeDvW7uDt4DqxL32O6r97HEFYhZAhxTM4Zmoec8Ebjr2bISn0XhpqFjIba82kYa8EtiClOA= 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=vm5hSF/2; arc=none smtp.client-ip=91.218.175.182 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="vm5hSF/2" Message-ID: <3ec76ffd-2650-4302-87e1-8183029a0553@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1780492168; 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=hcqvDrGcHqEyFCLA51sUV4Sc5w37DlSQfxQWt0KZ8ZE=; b=vm5hSF/2NMMHB/9RxcyxVabX5G0pPMxM3MBXwo2hruAmNw8p+8BB7iW6E5Lw1m/Qg3ONqK LlehzhHZ+6I1+4kLx4pskZkj9vvEHjEUhmPXkg7HGt+jp0pT0Sow0iX6wGiVHqYuSzn7TX YTfqFsFDUmLLFna9cX9Cx5HbP2mv6p8= Date: Wed, 3 Jun 2026 21:09:18 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [RFC PATCH 1/2] mm/secretmem: try to restore large page mappings in direct map To: Mike Rapoport 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 References: <20260603114134.3010-1-lance.yang@linux.dev> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Lance Yang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT 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 >>>> >>>> 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. > > 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 >> >