On 05/18/2010 04:08 AM, Glauber Costa wrote:
On Mon, May 17, 2010 at 09:38:30AM -1000, Zachary Amsden wrote:
On 05/17/2010 05:36 AM, Glauber Costa wrote:
On Fri, May 14, 2010 at 04:07:43PM -1000, Zachary Amsden wrote:
I believe this fixes the root cause of the kvmclock warp. It's
quite a plausible phenomenon, and explains why it was so easy to
produce.
You mean this is the case for both SMP and UP, or just UP as we talked
before?
It's possible on both SMP and UP, guest and host. It is impossible
on UP host unless special circumstances come into play (one of my
patches created these circumstances).
I don't get the role of upscale in your patch. Frequency changes are
already handled by the cpufreq notifier.
The only purpose of upscale is to downscale the measurement of delta
used for counting stats if CPU frequency was raised since last
observed. This is because moving to a faster TSC rate means we
might have counted some cycles at the wrong rate while the rate was
in transition. It doesn't much matter, as the delta for which
"overrun" is logged was computed wrong anyway.
mind sending the stats part in a separate patch?
Yeah, part of this was badly broken.
I'll clean up my patches and resend as a series today.
Zach
Or today. Nasty bug.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
