[Xen-devel] RE: TSC scaling and softtsc reprise, and PROPOSAL

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> And not specifying tsc_freq gets you
> current behaviour (pass through host TSC where possible). 

I fear that unless the default is changed, it will
not be possible to sufficiently explain the problem
to users/administrators and the option will not get
turned on. In which case, it might as well not be
done at all... just one more obscure option that
nobody understands or uses.

Given that correctness is at stake (and given that
Xen's primary competitors are choosing correctness
over performance), I see this as a Xen developer
problem to fix, not one to pawn off on harried
system admins.

Savvy system admins (who know every app in their
data center and/or are willing to take the risk
for better performance) should be able to easily
disable softtsc though on all servers with a xen boot
option, or on a per VM basis.

We could quibble about details (maybe softtsc
should only be automatically enabled on SMP guests
or on 64-bit SMP guests or ?? ) but I suspect
that just creates a mess and IMHO we should just
bite the bullet.

> -----Original Message-----
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
> Sent: Tuesday, July 28, 2009 9:00 AM
> To: Dan Magenheimer; Zhang, Xiantao; Ian Pratt; Xen-Devel (E-mail)
> Cc: John Levon; Dong, Eddie
> Subject: Re: TSC scaling and softtsc reprise, and PROPOSAL
> 
> 
> On 28/07/2009 15:45, "Dan Magenheimer" 
> <dan.magenheimer@xxxxxxxxxx> wrote:
> 
> > I am proposing that the virtual TSC be the default.
> > We should provide a per-VM option and a Xen boot
> > option to allow VMs to NOT trap rdtsc, but this
> > should have a warning that it is not recommended
> > and may result in data corruption in some apps.
> 
> This I can agree with. The softtsc boot option is just lazy. 
> This should
> properly be a per-VM option, for both HVM and PV guests. For example
> tsc_freq=x sets virtual TSC of x MHz. And not specifying 
> tsc_freq gets you
> current behaviour (pass through host TSC where possible). 
> That I could quite
> happily live with, although I'm not planning to implement it myself.
> 
>  -- Keir
> 
> 
>

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