On 11/24/2010 04:52 AM, Juan Quintela wrote:
"Michael S. Tsirkin"<m...@redhat.com> wrote:
On Wed, Nov 24, 2010 at 12:02:59AM +0100, Juan Quintela wrote:
From: Juan Quintela<quint...@trasno.org>
diff --git a/buffered_file.h b/buffered_file.h
index 98d358b..a728316 100644
--- a/buffered_file.h
+++ b/buffered_file.h
@@ -21,6 +21,8 @@ typedef void (BufferedPutReadyFunc)(void *opaque);
typedef void (BufferedWaitForUnfreezeFunc)(void *opaque);
typedef int (BufferedCloseFunc)(void *opaque);
+extern const int buffered_file_interval;
+
This shouldn't be exported, IMO.
What do you want? an accessor function? Notice that it is a constant.
We need the value in other places, see the last patch.
That one's just as wrong as this one. TBH, this whole series is
fundamentally the wrong approach because it's all ad hoc heuristics
benchmarked against one workload.
There are three fundamental problems: 1) kvm.ko dirty bit tracking
doesn't scale 2) we lose flow control information because of the
multiple levels of buffering which means we move more data than we
should move 3) migration prevents a guest from executing the device
model because of qemu_mutex.
Those are the problems to fix. Sprinkling the code with returns in
semi-random places because it benchmarked well for one particular test
case is something we'll deeply regret down the road.
Regards,
Anthony Liguori
Otherwise, I have to pick random numbers like ... 50ms.
Later, Juan.
QEMUFile *qemu_fopen_ops_buffered(void *opaque, size_t xfer_limit,
BufferedPutFunc *put_buffer,
BufferedPutReadyFunc *put_ready,
--
1.7.3.2
