[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] [PATCH] replace rdtsc emulation-vs-native xen boot option with per-domain (hypervisor part)


  • To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>, "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Zhang, Xiantao" <xiantao.zhang@xxxxxxxxx>
  • Date: Mon, 28 Sep 2009 16:22:34 +0800
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Cc:
  • Delivery-date: Mon, 28 Sep 2009 01:23:33 -0700
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: Aco/yQlnn/7zTom9TTSYttpEvykDRgASbNsw
  • Thread-topic: [Xen-devel] [PATCH] replace rdtsc emulation-vs-native xen boot option with per-domain (hypervisor part)

Dan Magenheimer wrote:
> Sorry I should have explained my logic for those changes
> in the original posting.
> 
> The scaling is a strange corner case where a domain
> can invisibly change from native-tsc to virtual-tsc.
> I started to add a domctl so that the current state
> could be probed, but decided that the scaling is
> really a policy decision that is best made at
> config time and best retained in the VM information
> carried along with a save file (or live migration).
> Allowing rdtsc to change dynamically according to
> whether a save/restore/migration happened to occur
> and whether the restored VM happened to land on
> a machine with a different clock rate seems like
> it could get very confusing.  The domain adminstrator
> either assumes correctness (the default) or turns
> off emulation to get better performance and deals
> with ALL the consequences.  So IMHO removing the
> scaling simplifies an already complex-to-explain
> issue. 
Hi, Dan
  I didn't see the necessity to remove the scaling logic.  This logic just 
allows the domain can run  in different TSC-freq platforms without strange 
timing behaviors.  If the domain is migrated between tow machines with 
different TSC rate, system administrator can get the tsc emulation knowledge 
from Xen's system log, and if administrator doesn't like to suffer performance 
loss in emulation way,  he can migrate the guest back.  Besides, I don't think 
this logic conflicts with your boot-stage option.IMO,  if the boot-stage option 
is set to use emulation, the scaling policy can be switched off, but if the 
option is not specified, I think the default scaling policy should be adopted 
in migration case.  
Xiantao

> 
>> -----Original Message-----
>> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>> Sent: Sunday, September 27, 2009 3:39 PM
>> To: Dan Magenheimer; Xen-Devel (E-mail)
>> Subject: Re: [Xen-devel] [PATCH] replace rdtsc emulation-vs-native
>> xen boot option with per-domain (hypervisor part)
>> 
>> 
>> On 27/09/2009 20:22, "Dan Magenheimer"
>> <dan.magenheimer@xxxxxxxxxx> wrote:
>> 
>>> (I'm still struggling against the coils of python on
>>> the tools part of this patch, so thought I'd post the
>>> hypervisor side separately first.)
>>> 
>>> Switches rdtsc emulation from boot option to per-domain
>>> and enables it by default.  Also removes hvm tsc scaling
>>> as it is no longer necessary.
>> 
>> The hvm tsc scaling will still be useful in the case that
>> trap-&-emulate was originally disabled for an hvm domain. So I'd
>> keep it, and 
>> also keep the
>> flag called d->arch.vtsc rather than flipping it and renaming
>> it, and the
>> patch will end up about 20 lines long.
>> 
>> I'll rework this patch myself and check it in at the same
>> time as the tools
>> patch, when you have that ready.
>> 
>>  -- Keir
>> 
>> 
>> 
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel
>> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.