[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: [Xen-devel] write_tsc in a PV domain?
> I think this is getting a bit repetitive. True, and we are going down some unfortunate ratholes. So let's see if we can focus on the core of the disagreement. > Apps are free to try and use the tsc in any way they > feel like, but it has never had any > GUARANTEED [djm's emphasis] properties. I think this is the key difference of opinion which must be resolved. If what you say is true, your other positions make sense. If it is false, they make much less sense. (And unfortunately it is not a black and white issue.) There ARE guaranteed properties specified by the Intel SDM for any _single_ processor, namely that rdtsc is "guaranteed to return a monotonically increasing unique value whenever executed, except for 64-bit counter wraparound. Intel guarantees that the time-stamp counter will not wrap-around within 10 years after being reset." Both uses of the word "guarantee" are quoted from the Intel SDM. What is NOT guaranteed, but is widely and incorrectly assumed to be implied and has gotten us into this mess, is that the same properties applies across multiple processors. And there are notable examples of systems where the properties do NOT apply. So it is true that an app that does not know conclusively that certain threads are running on certain processors cannot always safely use rdtsc to obtain the single-processor-guaranteed results. BUT some software systems (including VMware) do provide this guarantee across multiple processors. And recent families of both Intel and AMD multi-core have advanced to the point where the properties apply across all cores, so on the vast majority (but admittedly not all) of future physical systems, apps can and will use rdtsc and expect the properties to apply (whether guaranteed or not). So in your opinion, some systems are broken so Xen should assume all future systems are broken. In my opinion, the problem is being fixed in hardware and has always been fixed in VMware, so Xen should look to the future not the past. Does that sound like a good summary of this disagreement? P.S. Summarizing the broader discussion on a new thread. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |