[PATCH v4 10/17] KVM: arm64: Add a shrinker for pKVM

[Fuad Tabba]

On Tue, 25 Aug 2026 at 09:20, Vincent Donnefort <vdonnefort at google.com> wrote:
...
> > It would still fall through to the top-up pages once the chunks run
> > out, which is where your last point comes in. hyp_allocator_map() only
> > raises a request when it finds the mc empty, so pages sitting in there
> > are ones a top-up just put there for a retry. Could the reclaim leave
> > them alone altogether, and drop the mc.nr_pages term v4 added to
> > hyp_allocator_reclaimable(), which is what advertises them to the
> > shrinker?
>
> There's nothing that prevents a users from topping-up the allocator mc... but to
> never actually use the memory. That's why I think it is better to drain it.

Agreed, that settles it.

...

> > It's the retry that fails, not the reclaim. With target == 1,
> > hyp_allocator_drain_memcache() pops one page and target is done, so
> > the chunk loop never runs. But the top-up was sized to the exact
> > shortfall, so the retry now runs the mc dry one page early, sets
> > topup_needed = 1, returns -ENOMEM again, and pkvm_call_hyp_req() goes
> > round for another top-up.
> >
> > Nothing errors out, it just doesn't converge for as long as the
> > shrinker keeps pace.
> >
> > Keep in mind, I am not as familiar with this code as you are. So I
> > might be completely off here :)
>
> Ha yes, a concurrent topup with shrinking wouldn't cooperate well and I am not
> sure how better we can do. But note the shrinker always "scans" half of the
> reclaimable memory. So it is unlikely a user needs to top it up during
> shrinking: if we reclaim hyp allocator memory that's because there's plenty
> unused!
>
> But I am happy to start with the memory mapped into the allocator and then if
> necessary finish with the allocator->mc: if there are memory in allocator->mc
> that's probably because a topup is pending.

Sounds good. Would the tail ULONG_MAX drain need bounding too, so it
doesn't empty the mc regardless?

Thanks!
/fuad

>
> --
> Vincent
>
> >
> > Cheers,
> > /fuad
> >
> > > >
> > > > >
> > > > > However now looking at it. I wonder if I don't want to ratelimit here the number
> > > > > of pages reclaimed in one go to limit the time spent at EL2. Especially we do
> > > > > all that with the allocator lock taken...
> > > >
> > > > Ratelimiting would cap the time under the lock, but it wouldn't stop a
> > > > concurrent shrink from taking the topup pages, would it?
> > >
> > > Yes, my only intent is to avoid blocking at EL2 for too long.
> > >
> > > --
> > > Vincent
> > >
> > > >
> > > > Cheers,
> > > > /fuad
> > > >
> > > >
> > > > >
> > >
> > > [...]