On Fri, Apr 24, 2026 at 11:55:39AM -0400, Peter Xu wrote:
> For us, we know the overhead in theory, but we never really measured how
> much.
I think I didn't discuss the other side of things, where hypervisor can
touch some pages and mark it accessed, even if you don't want to.
IMHO we should track most of such accesses, except special cases.
One example is when the access happened because of emulated DMAs, then it
should be marked alongside to the guest access: that's when you mentioned
vhost, and I believe whatever vhost touched on the pages it should be
marked hot even the guest didn't touch it.
The special case is really migration that I can think so.
When at this, I also want to know whether you can benefit from something
like swap_access() / maccess() that I can propose when it's ready. It
means we can shift some corner case accesses from hypervisor to that API
then it won't cause false-positive even if rmap is involved. Then rmap
will be a pure perf issue, if it will still be an issue at all.
I can also share at least my plan on our side, in case it helps to find
shared goals. Basically we at least have two ways to go:
Plan A: propose maccess() then use it in qemu for migration purpose.
migration is so far the only thing we want to rule out. We want to
keep DMAs access promote pages, for example. This will keep
relying on kernel to do hotness tracking and evictions. IMHO the
best and simplest solution so far taking both user+kernel into
account.
Plan B: if above didn't work, we can implement swap in qemu. We need some
API like what you're looking for, except that the major challenge
to us is MGLRU compatibility.
So IIUC if you're looking for completely flexible swap backends, then Plan
A won't work for you: that'll always stick with kernel's swapfile
managements and it's not always flexible enough. Then I want to look if we
can share goal in plan B. But if we can find some shared goal in plan A /
maccess(), then I'll also be more than willing to know. For that part I
can definitely see what I can do.
Thanks,
--
Peter Xu
