On Thu, Feb 07, 2019 at 05:33:25PM -0500, Neil Skrypuch wrote: Thanks for your email!
Please post your QEMU command-line. > The clock jump numbers above are from NTP, but you can see that they are > quite > close to the amount of time spent in raw_co_invalidate_cache. So, it looks > like flushing the cache is just taking a long time and stalling the guest, > which causes the clock jump. This isn't too surprising as the entire disk > image was just written as part of the block mirror and would likely still be > in the cache. > > I see the use case for this feature, but I don't think it applies here, as > we're not technically using shared storage. I believe an option to toggle > this > behaviour on/off and/or some sort of heuristic to guess whether or not it > should be enabled by default would be in order here. It would be good to figure out how to perform the flush without affecting guest time at all. The clock jump will also inconvenience users who do need the flush, so I rather not work around the clock jump for a subset of users only. Stefan
signature.asc
Description: PGP signature
