[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [regression] Clock jump on VM migration
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [regression] Clock jump on VM migration |
Date: |
Fri, 8 Feb 2019 14:24:41 +0800 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
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