[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 06 Jun 2007 12:52:59 +0100
From: Keir Fraser <keir@...source.com>
To: Jan Beulich <jbeulich@...ell.com>
CC: Jeremy Fitzhardinge <jeremy@...p.org>,
Xen-devel <xen-devel@...ts.xensource.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Andi Kleen <ak@...e.de>, lkml <linux-kernel@...r.kernel.org>,
Chris Wright <chrisw@...s-sol.org>,
<virtualization@...ts.osdl.org>, Ingo Molnar <mingo@...e.hu>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [Xen-devel] [patch 14/33] xen: xen time implementation
On 6/6/07 12:00, "Jan Beulich" <jbeulich@...ell.com> wrote:
>> If the error across CPUS is +/- just a few microseconds at worst then having
>> the clocksource clamp to no less than the last timestamp returned seems a
>> reasonable fix. Time won't 'stop' for longer than the cross-CPU error, and
>> that should always be a tiny value.
>
> Are you sure this is also true when e.g. a CPU gets throttled due to thermal
> conditions? It is my understanding that both the duty cycle adjustment and
> the frequency reduction would yield a reduced rate TSC, which would be
> accounted for only the next time the local clock gets calibrated. Otherwise,
> immediate calibration (and vcpu update) would need to be forced out of the
> thermal interrupt.
Yes, this could be an issue. Is there any way to get an interrupt or MCE
when thermal throttling occurs?
-- Keir
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists