[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Relative/Absolute timing snapshot problem
From: |
Clemens Kolbitsch |
Subject: |
[Qemu-devel] Relative/Absolute timing snapshot problem |
Date: |
Fri, 18 Mar 2011 13:39:33 -0700 |
User-agent: |
KMail/1.13.5 (Linux/2.6.35-28-generic; KDE/4.5.1; x86_64; ; ) |
Hi list,
strange situation: When I create a snapshot using Qemu 0.14.0 stable,
everything works smoothly and resuming the CPU takes about 1-2 seconds. If I
don't use the snapshot file for some time, the time it takes to resume grows
by 2-3 seconds per day. At the moment, I'm looking at a snapshot file from
last week and it takes nearly 30 seconds to load.
Funny thing about it: if I turn my system time back to the date when the
snapshot was created (or before that), resuming CPU works within the expected
1-2 seconds. I have _very briefly_ looked into it and it seems like Qemu
spends an aweful long amount of time catching up with timer execution -- is it
possible that these are stored using absolute time instead of relative timing?
I am using qcow2 file format, because I absolutely rely on CPU-snapshots and
support for base-files. I have read here and there that it is more or less
broken (or at least very slow), but with the correct cache-options it works
for me (except for this bug, of course).
Has anyone encountered this or should I start looking into it (although I have
some experience with the core source, I'm not very experienced with the
snapshotting code).
Thanks,
Clemens
- [Qemu-devel] Relative/Absolute timing snapshot problem,
Clemens Kolbitsch <=