John Levon wrote:
> On Thu, Jun 18, 2009 at 08:58:49AM -0700, Dan Magenheimer wrote:
>
>> Other apps (and/or the OS kernel) may use TSC to
>> approximate the passage of time, and for these apps
>> (and gettimeofday in the Linux kernel), this TSC scaling
>> patch is a must. Unfortunately, both kinds of apps could
>> be running simultaneously on the same guest. And
>> in either case, RDTSC frequency may be quite high.
>
> Certainly Solaris relies on the TSC for time-keeping, and uses it very
> heavily. To the extent that I doubt it's even feasible to migrate to a
> machine where scaling needs to be done, and such a migration should be
> refused, since it would essentially kill the guest.
>
>> question is: If it is important to ALWAYS emulate RDTSC,
>> can the Xen code be written to handle RDTSC emulation
>> much faster? If it could be made fast enough, the
>
> I'd be amazed if this were possible.
Actually, we had done some optimizations and make most of rdtsc not trap to
hypervisor and always keep tsc monotonically increasing in each virtual
processor, but it is hard to solve the tsc drift issue between all vcpus. In
our solution, tsc drift may exceeds 100000 cycles. You know, TSC drift maybe
also exist in real platforms, but maybe not quite large like 1000000 cycles. Do
you know what's the limit of tsc drift OS or applications can bear? At least,
Linux doesn't care about the drift much, but don't have no idea about
applicatoin's behavior for such large drift.
Xiantao
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home