kata-containers/cloud-hypervisor
1
0
Fork 0
mirror of https://github.com/cloud-hypervisor/cloud-hypervisor.git synced 2026-08-05 02:19:16 +00:00
Code Issues Packages Projects Releases Wiki Activity

vmm: avoid creating large temporary vector during migration

Browse Source 
... by just passing the iterator along. For large VMs this bitmap is
gigantic. A 12TB VM has 384MB of dirty bitmap.

With all these optimizations from the previous commits in place, we
see quite the improvement when it comes to scanning the dirty bitmap.

For a bitmap with 1% bits (randomly) set, dirty_log() takes:

Original code: 2166ms (100.0%)
New code:       382ms ( 17.6%)

on my system. The sparser the dirty bitmap the faster. Scanning an
empty bitmap is 100x faster. For a 5% populated bitmap we are still 3x
faster.

If someone wants to play with this, there is a benchmark harness here:
https://github.com/blitz/chv-bitmap-bench

On-behalf-of: SAP julian.stecklina@sap.com
Signed-off-by: Julian Stecklina <julian.stecklina@cyberus-technology.de>
This commit is contained in:
Julian Stecklina
2025-11-07 15:06:05 +01:00
committed by Rob Bradford
parent fc99e299c3
commit b6c266c880
1 changed files with 2 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
vmm/src/memory_manager.rs
View File

@@ -2600,11 +2600,10 @@ impl Migratable for MemoryManager {
}
};
let dirty_bitmap: Vec<u64> = vm_dirty_bitmap
let dirty_bitmap = vm_dirty_bitmap
.iter()
.zip(vmm_dirty_bitmap.iter())
.map(|(x, y)| x | y)
.collect();
.map(|(x, y)| x | y);
let sub_table = MemoryRangeTable::from_bitmap(dirty_bitmap, r.gpa, 4096);