From mboxrd@z Thu Jan  1 00:00:00 1970
From: Andi Kleen <andi@firstfloor.org>
Subject: Re: Cross vendor migration ideas
Date: Mon, 17 Nov 2008 12:09:34 +0100
Message-ID: <20081117110934.GH6703@one.firstfloor.org>
References: <982D8D05B6407A49AD506E6C3AC8E7D6BEF936912A@caralain.haven.nynaeve.net> <7CCF7468C07AFF4B991DD1528058EC2F042C7283@SSVLEXMB1.amd.com> <878wrl16q5.fsf@basil.nowhere.org> <1FF5F416-082C-4FA2-8392-8552BFBEDA00@suse.de> <491F08F1.40501@firstfloor.org> <49203DFE.1070101@redhat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Andi Kleen <andi@firstfloor.org>, Alexander Graf <agraf@suse.de>,
	"Serebrin, Benjamin (Calendar)" <Benjamin.Serebrin@exchange.amd.com>,
	Skywing <Skywing@valhallalegends.com>,
	Anthony Liguori <anthony@codemonkey.ws>, kvm@vger.kernel.org,
	Amit Shah <amit.shah@redhat.com>,
	"Wahlig, Elsie" <elsie.wahlig@amd.com>,
	"Nakajima, Jun" <jun.nakajima@intel.com>
To: Avi Kivity <avi@redhat.com>
Return-path: <kvm-owner@vger.kernel.org>
Received: from one.firstfloor.org ([213.235.205.2]:46043 "EHLO
	one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751945AbYKQK74 (ORCPT <rfc822;kvm@vger.kernel.org>);
	Mon, 17 Nov 2008 05:59:56 -0500
Content-Disposition: inline
In-Reply-To: <49203DFE.1070101@redhat.com>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

> Long running guests on a large farm shouldn't expect to stay on the same 
> host they were booted on.  

If they change frequently and the vendors are even matched in the farm
their chance of running "fast" again will be quite good. The only
worst case would be to start on one vendor, run for a short time
there and then spend all the remaining time on the other. Most other
cases would be better.

Also again I wouldn't expect the impact to be that dramatic. While
there are some workloads which are syscall latency sensitive (and not rely
on the vsyscalls) a lot of others are not. 

> But at least for Linux, if we notify the 
> guest telling it to retune (which can include the vsyscall path) we can 
> avoid the cost entirely.

Hmm, we discussed something like this some time ago anyways (add
a way to rescan CPUID features) because there are microcode updates
around that change some (relatively obscure) CPUID features.

But doing it fully general would be likely quite intrusive. You 
would need to rewrite the CPU initialization code and some other
code in a callback like matter like the PCI code does for hotplug.

I doubt doing that would be worth the effort in real performance gains.

-Andi

-- 
ak@linux.intel.com