[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] [RFC] [PATCH] use "reliable" tsc properly when available, but verify
> From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] > > Given that TSC is now emulated, who cares what the underlying > CPUs say about > TSC reliability. Xen emulates the TSC with its own system > time, and even > explicitly checks that the returned TSC value is > monotonically increasing. > So TSC is alweays 'reliable' for guests, regardless of host > TSC behaviour. > So on this count, too, the patch is a reject. Ouch. I thought RFC was "request for comment", not "request for castration" ;-) ;-) Let me clarify my intent: I remain very much committed to emulated-tsc ("correctness") as the default for unmodified apps even if there is a significant loss of performance. Call this Phase I BUT I am continuing to work on how an "aware" app (or an "aware" OS) in a constrained environment can obtain both correctness AND performance. Call this Phase II. Pvrdtscp and Xiantao's scaling are different approaches to Phase II, for pvm and hvm respectively. Vsyscall+pvclock also if a PV OS can be made aware whether tsc_native is enabled or not. This proposed patch is really only important for Phase II, but given all the confusion around whether tsc is reliable/safe/constant/nonstop on various machines, I think it might be good to get code into Xen -- sooner rather than later -- that "measures" this so we can confirm if the promises made by processor and system vendors are (or are not) being delivered. Does that make more sense? Thanks, Dan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |