On Mon, Apr 27, 2020 at 01:14:33PM +0100, Dr. David Alan Gilbert wrote: > * Denis Plotnikov (dplotni...@virtuozzo.com) wrote: > > The patch adds ability to qemu-file to write the data > > asynchronously to improve the performance on writing. > > Before, only synchronous writing was supported. > > > > Enabling of the asyncronous mode is managed by new > > "enabled_buffered" callback. > > It's a bit invasive isn't it - changes a lot of functions in a lot of > places! > The multifd code separated the control headers from the data on separate > fd's - but that doesn't help your case. > > Is there any chance you could do this by using the existing 'save_page' > hook (that RDMA uses). > > In the cover letter you mention direct qemu_fflush calls - have we got a > few too many in some palces that you think we can clean out?
When I first introduced the QIOChannel framework, I hoped that we could largely eliminate QEMUFile as a concept. Thus I'm a bit suspicious of the idea of introducing more functionality to QEMUFile, especially as the notion of buffering I/O is rather generic. Is there scope for having a QIOChannelBuffered object for doing buffering. Would that provide better isolation from the migration code and thus be less invasive/complex to maintain ? Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
