On 3/11/19 12:36 PM, Vladimir Sementsov-Ogievskiy wrote: >> FWIW - I have not yet reviewed this series closely, but I think it would >> be wise to get this initial cut in before softfreeze (we can make >> further tweaks to fix bugs in assumptions during rc1 and rc2, but it's a >> lot harder to add the series at all if it misses softfreeze). >> > > I still not convinced that we need bitmap flushing. I think (and Den supports > me) that it's a bad idea. It makes things more difficult without a reason, > except improving debugging with --force-share which should never be used in > production.
And I'm still not convinced that adding bitmap flushing will add a benchmarkable delay to operation. Although debugging may not be needed in a production environment, having it after a failure can be a lifesaver. Looking at this from another point of view: if this series goes in now (with its use of limited bitmap flushing on resize in order to make coding bitmap resize easier, rather than global bitmap flushing after every bitmap add/delete), then the only time that flushing to disk happens is during resize (which is currently flat-out forbidden), so it will not penalize existing use cases. And we still have rc1/rc2 to fix any bugs if we can come up with some other way to get resize to work without flushing (or even revert things if it proves to be too invasive). But as a feature addition, if this series does not go in now, then bitmap resize is stuck waiting for 4.2, regardless of what we can figure out during rc1/rc2. > > Bitmaps are stored in qcow2_inactivate() which is true place for flushing > caches. > There doesn't have to be just one place for flushing caches. In terms of IOPs, how much overhead does a flush cost in relation to everything else? And how infrequent are bitmap resize, add, and delete events? Optimizing to the bare minimum of flushes just because it adds minimal overhead may be premature optimization if that overhead is in the noise anyway. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
