On 04/11/2012 05:14 PM, Takuya Yoshikawa wrote: > On Wed, 11 Apr 2012 20:38:57 +0800 > Xiao Guangrong <xiaoguangrong@xxxxxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
