[lkml]   [2012]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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 <> 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

 \ /
  Last update: 2012-04-11 16:25    [W:0.109 / U:4.752 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site