On Wed, Nov 24, 2010 at 12:13:26PM +0100, Juan Quintela wrote: > "Michael S. Tsirkin" <m...@redhat.com> wrote: > > On Wed, Nov 24, 2010 at 11:52:25AM +0100, 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? > > > > I mean an abstraction at qemu_file_ level. > > > >> Notice that it is a constant. > >> We need the value in other places, see the last patch. > >> > >> Otherwise, I have to pick random numbers like ... 50ms. > >> > >> Later, Juan. > > > > If you need a random number, use a random number :) > > It is not random, it is the bigger number that lets the timer to run at > each 100ms O:-)
The fact that buffered_file uses a timer internally is an implementation detail: arch_init uses the qemu file abstraction. > I tried 100ms and 75ms, they got better throughput, but I got still > stalls of 1.5s. > > I could do some search between 50 and 75ms, but the advantage in > bandwidth is not so big to complicate things. (150 vs 125s for total > migration time or so, and system is quite irresponsive with the bigger > value). > > Later, Juan.
