Re: [PATCH v11 4/6] x86/sev: Add support to perform RMP optimizations asynchronously
Dave Hansen <[email protected]> Wed, 5 Aug 2026 08:12:45 -0700
| Newsgroups | org.kernel.vger.linux-crypto,dev.linux.lists.linux-coco,org.kernel.vger.kvm,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 8/4/26 17:49, Borislav Petkov wrote: >> and dropped because of being too disruptive — a timer-based scan would run >> on all cores every time it fires, even when no memory has been freed. > What if it ran very seldomly, say once an hour? The kernel knows what events open up the system to new RMP optimizations. They don't happen randomly or without the kernel knowing. A scan once an hour for very long-lived guests will waste resources once an hour. A scan once an hour when guests have shorter lifetimes means that there will be hour-long windows when the system could have been optimized but was not. >> Running it at guest teardown (batched by the timeout) is a better fit: >> teardown is when large contiguous regions actually go back to the >> hypervisor, so the scan only runs when there's real work to do instead of on >> a fixed timer. The case of a guest freeing a 1 GB region mid-life is then >> handled by the 1 GB-hugetlb page-cleanup follow-on, not by a periodic scan. > Are you saying a periodic scan won't handle anything? A periodic scan could be useful but only if it coincides with a VM teardown event, or other event that opens up new RMP optimizations. I _think_ we decided that with current upstream code, the only event that matters is VM teardown. The thing I really don't like about picking an arbitrary window is that there's no right or wrong time. Folks are then going to want to tune it. They're going to want knobs, and ABI and documentation.