WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [patch 14/33] xen: xen time implementation

To: "Keir Fraser" <keir@xxxxxxxxxxxxx>, "Jan Beulich" <jbeulich@xxxxxxxxxx>
Subject: RE: [Xen-devel] [patch 14/33] xen: xen time implementation
From: "Petersson, Mats" <Mats.Petersson@xxxxxxx>
Date: Wed, 6 Jun 2007 13:58:46 +0200
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 06 Jun 2007 04:57:37 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C28C5EAB.1024D%keir@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AceoMTpmeRN5yhQkEdyEZAAX8io7RQAAD5xA
Thread-topic: [Xen-devel] [patch 14/33] xen: xen time implementation
 

> -----Original Message-----
> From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Keir Fraser
> Sent: 06 June 2007 12:53
> To: Jan Beulich
> Cc: Jeremy Fitzhardinge; Xen-devel; lkml; Andi Kleen; Chris 
> Wright; virtualization@xxxxxxxxxxxxxx; Thomas Gleixner; 
> Andrew Morton; Linus Torvalds; Ingo Molnar
> Subject: Re: [Xen-devel] [patch 14/33] xen: xen time implementation
> 
> 
> 
> 
> On 6/6/07 12:00, "Jan Beulich" <jbeulich@xxxxxxxxxx> 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?

As far as I'm aware, no. The normal way to "throttle" a procoessor is a
Pulse-Width-modulation on the STOPCLK pin, and the duration is in the
order of microseconds, so an interrupt every few microseconds may not
leave much room for the processor to actually do ANYTHING at that point.


Of course, it would be possible to design such hardware that does
clock-throttling to indicate "Clock throttling started" and "clock
throttling stopped" or some such, but as far as I'm aware, this is not
how it works. 

Some thermal sensors can give interrupts at certain levels of
temperature, but that's not the same as start/stop clock throttling. 
[I reduced the distribution list a bit - I'm not sure if everyone needs
to understand/know my thoughts on this subject]

--
Mats
> 
>  -- Keir
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
> 
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel