On Wed, Jun 12, 2024 at 07:15:19PM +0100, Daniel P. Berrangé wrote: > IIUC, with the "fixed-ram" feature, the on-disk format of a saved VM > should end up the same whether we're using traditional migration, or > multifd migration. Use of multifd is simply an optimization that lets > us write RAM in parallel to the file, with direct-io further optimizing. > > There's also a clear break with libvirt between the existing on-disk > format libvirt uses, and the new fixed-ram format. So we have no backwards > compatibilty concerns added from multifd, beyond what we already have to > figure out when deciding on use of 'fixed-ram'. > > Thus I believe there is no downside to always using multifd for save > images with fixed-ram, even if we only want nchannels=1.
That sounds good. Just to double check with all of us: so we allow mapped-ram to be used in whatever case when !dio, however we restrict dio only when with multifd=on, am I right? I'd personally like that, and it also pretty much matches with what we have with tcp zerocopy send too. After all they're really similar stuff to me on pinning implications and locked_vm restrictions. It's just that the target of the data movement is different here, either to NIC, or to/from a file. Thanks, -- Peter Xu
