Re: [RFC PATCH v1 00/26] migration: File based migration with multifd and fixed-ram

[Peter Xu]

On Fri, Mar 31, 2023 at 11:37:50AM -0300, Fabiano Rosas wrote:
> >> Outgoing migration to file. NVMe disk. XFS filesystem.
> >> 
> >> - Single migration runs of stopped 32G guest with ~90% RAM usage. Guest
> >>   running `stress-ng --vm 4 --vm-bytes 90% --vm-method all --verify -t
> >>   10m -v`:
> >> 
> >> migration type  | MB/s | pages/s |  ms
> >> ----------------+------+---------+------
> >> savevm io_uring |  434 |  102294 | 71473
> >
> > So I assume this is the non-live migration scenario.  Could you explain
> > what does io_uring mean here?
> >
> 
> This table is all non-live migration. This particular line is a snapshot
> (hmp_savevm->save_snapshot). I thought it could be relevant because it
> is another way by which we write RAM into disk.

I see, so if all non-live that explains, because I was curious what's the
relationship between this feature and the live snapshot that QEMU also
supports.

I also don't immediately see why savevm will be much slower, do you have an
answer?  Maybe it's somewhere but I just overlooked..

IIUC this is "vm suspend" case, so there's an extra benefit knowledge of
"we can stop the VM".  It smells slightly weird to build this on top of
"migrate" from that pov, rather than "savevm", though.  Any thoughts on
this aspect (on why not building this on top of "savevm")?

Thanks,

> 
> The io_uring is noise, I was initially under the impression that the
> block device aio configuration affected this scenario.
> 
> >> file:           | 3017 |  855862 | 10301
> >> fixed-ram       | 1982 |  330686 | 15637
> >> ----------------+------+---------+------
> >> fixed-ram + multifd + O_DIRECT
> >>          2 ch.  | 5565 | 1500882 |  5576
> >>          4 ch.  | 5735 | 1991549 |  5412
> >>          8 ch.  | 5650 | 1769650 |  5489
> >>         16 ch.  | 6071 | 1832407 |  5114
> >>         32 ch.  | 6147 | 1809588 |  5050
> >>         64 ch.  | 6344 | 1841728 |  4895
> >>        128 ch.  | 6120 | 1915669 |  5085
> >> ----------------+------+---------+------
> >
> > Thanks,
> 

-- 
Peter Xu