Re: [PATCH v11 4/6] x86/sev: Add support to perform RMP optimizations asynchronously

On 8/4/2026 7:49 PM, Borislav Petkov wrote:
> On Mon, Aug 03, 2026 at 05:22:17PM -0500, Kalra, Ashish wrote:
>> Periodic re-optimization was already considered in an earlier RMPOPT series
> 
> Link?

Re-optimizing at guest termination rather than via a periodic/runtime interface was Dave Hansen's suggestion in the v2
review — see https://lore.kernel.org/kvm/[email protected]/"

> 
>> 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?
> 
>> 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?
> 
> Because if it catches something, it will handle that something.
A couple more reasons the event-driven trigger fits better than a fixed period:

- Under churn (many SNP guests terminating and respawning), an hourly scan is too coarse — freed regions would sit
un-optimized for up to an hour. The teardown trigger re-optimizes right after each burst of terminations (batched by the
timeout), so it's more responsive than a periodic scan exactly when there's the most optimization work to do.
- When no SNP guests run, a periodic scan achieves nothing: the initial pass already optimized all of memory and
nothing has changed, so it just re-scans physmem for zero benefit.

So the event-driven approach self-scales with real work — it runs as often as memory is actually freed and not at all
when the system is idle — whereas a fixed timer is both too slow under load and pure overhead when idle. The mid-life
contiguous-1 GB case is then caught precisely by the 1 GB-hugetlb page-cleanup hook when that lands, rather than by a
coarse sweep.

Thanks,
Ashish

> 
>> I will also like to avoid looping on this — periodic vs teardown was already
>> worked through in an earlier revision, and this is where we landed. Happy to
>> revisit if there's a specific new concern, but otherwise I'd prefer to keep
>> the current approach.
> 
> Sorry, this is not how upstream review works.
>