Re: [PATCH 00/13] KVM: MMU: fast page fault

[Avi Kivity]

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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/