xl: relax freemem()'s retry calculation
authorJan Beulich <jbeulich@suse.com>
Wed, 27 Jul 2022 07:14:32 +0000 (09:14 +0200)
committerJan Beulich <jbeulich@suse.com>
Wed, 27 Jul 2022 07:14:32 +0000 (09:14 +0200)
commit6f814c377bb6959af0f8e74edc2582e14c427091
treeaae78a7fcb3ee3f9e2a5ad9999b475ae4767f436
parent221f6a97b59e008f11eb310ad0c9b802f3bea233
xl: relax freemem()'s retry calculation

While in principle possible also under other conditions as long as other
parallel operations potentially consuming memory aren't "locked out", in
particular with IOMMU large page mappings used in Dom0 (for PV when in
strict mode; for PVH when not sharing page tables with HAP) ballooning
out of individual pages can actually lead to less free memory available
afterwards. This is because to split a large page, one or more page
table pages are necessary (one per level that is split).

When rebooting a guest I've observed freemem() to fail: A single page
was required to be ballooned out (presumably because of heap
fragmentation in the hypervisor). This ballooning out of a single page
of course went fast, but freemem() then found that it would require to
balloon out another page. This repeating just another time leads to the
function to signal failure to the caller - without having come anywhere
near the designated 30s that the whole process is allowed to not make
any progress at all.

Convert from a simple retry count to actually calculating elapsed time,
subtracting from an initial credit of 30s. Don't go as far as limiting
the "wait_secs" value passed to libxl_wait_for_memory_target(), though.
While this leads to the overall process now possibly taking longer (if
the previous iteration ended very close to the intended 30s), this
compensates to some degree for the value passed really meaning "allowed
to run for this long without making progress".

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
master commit: e58370df76eacf1f7ca0340e9b96430c77b41a79
master date: 2022-07-12 15:25:00 +0200
tools/xl/xl_vmcontrol.c