mirror of
https://github.com/xen-project/xen.git
synced 2026-10-28 02:01:24 +01:00
Jan Beulich
e58370df76
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>