qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Question with migrate_set_speed


From: Peter Xu
Subject: Re: [Qemu-devel] Question with migrate_set_speed
Date: Fri, 19 Aug 2016 17:22:46 +0800
User-agent: Mutt/1.5.24 (2015-08-30)

On Fri, Aug 19, 2016 at 09:13:15AM +0100, Dr. David Alan Gilbert wrote:
> Actually, that's what QEMU does; the migrate_set_speed is really only used
> for (1) directly.
> (2) actually comes from a measured bandwidth multiplied by the 
> 'migrate_set_downtime'
> figure. (See around line 1800ish i migration/migration.c inside
> the if (current_time >= initial+time + BUFFER_DELAY) if ).

You are right. Sorry I didn't notice that. :(

> 
> 
> > We can set_speed to a very small value to avoid disturbing other
> > network services, that's good. However using the same value to
> > estimate "when to stop" seems odd, since this value can be far away
> > from the real network speed (when we are transfering the last bits in
> > precopy, we should be using the max network speed all the time, which
> > actually is not affected by the threshold value).
> > 
> > IMHO, it'll be clearer if these are two different tunables, e.g., not
> > sure whether it'll be cool to add another tunable "set_speed_max", to
> > configure the speed for the (2) case (when vm is stopped on source).
> > If so, it'll be clearer, and also bring another benefit: users can
> > have full control of the last migration phase as well, in case they
> > don't want to suffer from a network fluctuation for each ends of
> > migration.
> > 
> > Still haven't thought further. Just throw this question out.
> 
> I don't think people are very good at setting the two tunables we already
> have!

Then I think current tunables are good enough at least to me. And only
to control the last bit transfer seems not essential to introduce
another one. Thanks!

-- peterx



reply via email to

[Prev in Thread] Current Thread [Next in Thread]