Messages in this thread |  | | Date | Wed, 11 Apr 2012 17:21:30 +0300 | | From | Avi Kivity <> | | Subject | Re: [PATCH 00/13] KVM: MMU: fast page fault |
| |
On 04/11/2012 05:14 PM, Takuya Yoshikawa wrote: > On Wed, 11 Apr 2012 20:38:57 +0800 > Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> wrote: > > > Well, my point is that live migration is so very useful that it is worth > > to be improved, the description of your also proves this point. > > > > What is your really want to say but i missed? > > How to improve and what we should pay for that. > > Note that I am not objecting to O(1) itself. > > Do you remember that when we discussed O(1) issue last year, with Avi, > the agreement was that we should take more time and look carefully > with more measurements to confirm if it's really worthwhile. > > The point is whether we should do O(1) now, including near future. > > My opinion is that we should do what we can do now and wait for feedback > from real users. > > Before making the current code stable, I do not want to see it replaced > so dramatically. Otherwise when can we use live migration with enough > confidence? There may be another subtle bugs we should fix now. > > In addition, XBRZLE and post-copy is now being developed in QEMU. > > > What do you think about this Avi, Marcelo?
Currently the main performance bottleneck for migration is qemu, which is single threaded and generally inefficient. However I am sure that once the qemu bottlenecks will be removed we'll encounter kvm problems, particularly with wide (many vcpus) and large (lots of memory) guests. So it's a good idea to improve in this area. I agree we'll need to measure each change, perhaps with a test program until qemu catches up.
> I am testing the current live migration to see when and for what it can > be used. I really want to see it become stable and usable for real > services.
Well, it's used in production now.
> > Okay, let us to compare the performance number after O(1) implemented. > > From my experience, I want to say that live migration is very difficult > to say about performance. That is the problem I am now struggling with. > > I developed dirty-log-perf unit-test for that but that was not enough. > > Needless to say, checking the correctness is harder. > > > So I really do not want to see drastic change now without any real need > or feedback from real users -- this is my point. >
It's a good point, we should avoid change for its own sake.
-- error compiling committee.c: too many arguments to function
|  |