Currently pit irq is enabled when using pit as clocksource or taking pit as broadcast means for deep C-state. I''m curious whether pit irq is really required for the 1st case. When pit is chosen as clocksource, 10ms periodical pit interrupt converts 16 counter into monotonic 32bit stamp, and then ~27ms platform overflow timer converts 32bit into 64bit stamp. Is the first conversion really necessary? platform overflow timer is chosen as 1/2 period, and it looks safe enough to convert from 16bit into 64bit stamp directly. Just one special bit to indicate whether counter counts down or up. Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 On 19/11/08 02:01, "Tian, Kevin" <kevin.tian@intel.com> wrote:> Currently pit irq is enabled when using pit as clocksource or > taking pit as broadcast means for deep C-state. I''m curious > whether pit irq is really required for the 1st case. When pit > is chosen as clocksource, 10ms periodical pit interrupt converts > 16 counter into monotonic 32bit stamp, and then ~27ms platform > overflow timer converts 32bit into 64bit stamp. Is the first > conversion really necessary? platform overflow timer is chosen > as 1/2 period, and it looks safe enough to convert from 16bit > into 64bit stamp directly. Just one special bit to indicate > whether counter counts down or up. > > Thanks, > Kevin_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] >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@lists.xensource.com http://lists.xensource.com/xen-devel
On 19/11/08 08:22, "Tian, Kevin" <kevin.tian@intel.com> wrote:> 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.Most systems will have ACPI PM or HPET timer though, right? Does PIT platform timer inefficiency matter? Hacking on it more is a pain. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
>From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] >Sent: Wednesday, November 19, 2008 4:50 PM > >On 19/11/08 08:22, "Tian, Kevin" <kevin.tian@intel.com> wrote: > >> 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. > >Most systems will have ACPI PM or HPET timer though, right? Does PIT >platform timer inefficiency matter? Hacking on it more is a pain. > > -- Keir >Agree. Thanks, Kevin _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel