[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] RE: About pit irq


  • To: 'Keir Fraser' <keir.fraser@xxxxxxxxxxxxx>, 'xen-devel' <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
  • Date: Wed, 19 Nov 2008 16:22:52 +0800
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Cc:
  • Delivery-date: Wed, 19 Nov 2008 00:23:16 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AclJ6rZmkfZkqKK6QNCPP6epkry8AQANMC+dAAAN6CA=
  • Thread-topic: About pit irq

>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx] 
>Sent: Wednesday, November 19, 2008 4:19 PM
>
>Since the PIT advertises itself as a 32-bit timer, the 
>platform overflow
>logic will not trigger every 27ms. More like once an hour.
>
>The issue with PIT is the 16-bit counter overflows within 10s of
>milliseconds, and we have non-preemptible periods in Xen of 
>longer than that
>(e.g., during domain destruction). If we miss an overflow, 
>time handling
>gets totally screwed so we have to deal with PIT in hardirq 
>context, not
>softirq. We do it at 10ms because that's what we happen to 
>always program
>PIT for. Certainly in this specific case we could program it 
>to tick slower.
>
> -- Keir
>

I see. Yes, a slower tick is better since maximum overflow for
pit ch2 is about 54ms, and xen has already be a tickless
model.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.