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] [RFC] Remove the x86 Periodic 100HZ PIT Timer Interrupt

To: "Yu, Ke" <ke.yu@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] Remove the x86 Periodic 100HZ PIT Timer Interrupt
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Mon, 07 Apr 2008 11:03:46 +0100
Delivery-date: Mon, 07 Apr 2008 03:05:15 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1104166E0B63A341805FDB977862AAD2015A4DE0@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: AciYkFQNYmyqI0NSRKuabH1qVznbFQABlbck
Thread-topic: [Xen-devel] [RFC] Remove the x86 Periodic 100HZ PIT Timer Interrupt
User-agent: Microsoft-Entourage/11.4.0.080122
On 7/4/08 10:18, "Yu, Ke" <ke.yu@xxxxxxxxx> wrote:

> * How to handle jiffies
> Since there are only several places using jiffies (see below), so it is
> easy to replace jiffies by NOW() API
> xen\drivers\passthrough\vtd\intremap.c
> xen\drivers\passthrough\vtd\iommu.c

Yes, they should have been implemented that way in the first place.

> xen\arch\x86\io_apic.c

No, since the whole point of using jiffies is to check that irq0 is working.
My advice is to leave PIT (irq0) setup as-is during boot, and then disable
PIT channel 0 at end of boot if you detect that it is not required (i.e.,
you have local APIC, and you are not using PIT as platform time source).

> * How to raise TIMER_SOFTIRQ if CPU has no APIC
> Since it rare that CPU has no APIC, so this case will not be optimized.
> If CPU has no APIC support, we will still use PIT timer to raise
> TIMER_SOFTIRQ

Agreed.

> * How to handle platform timer counter overflow
> Since IBM cyclone timer/HPET timer/ACPI PM timer has large overflow
> period (> 1s), so it is safe to use AC timer to handle the overflow. For
> PIT timer counter, it has pretty small overflow period (0.055s), so
> still use PIT timer interrupt to handle PIT timer counter overflow, to
> guarantee its accuracy.

Agreed.

> P.S. the platform timer counter overflow period is as follow
>     - IBM cyclone timer 32bit counter overflows every 42.9s
>     - HPET timer 32bit counter overflows every ~300s (in ICH7/8/9)
>     - ACPI PM timer 24bit counter overflows every 4.6s
>     - PIT timer 16bit counter overflows every 0.055s

Well, bear in mind that we actually schedule the overflow handler when the
counter is halfway to being wrapped. So actually we schedule overflow
handling for the above timers every 21.5s, 150s, 2.3s and 0.028s,
respectively.

It is okay to use ac_timer logic, triggered off softirq, if we are sure that
softirq work is guaranteed to be done often enough that the overflow handler
will run before the counter actually overflows. Ignoring the PIT, this means
we need a worst-case softirq schedule-to-execute latency of 2.3s, which
seems pretty reasonable to expect!

> In summary, to remove the PIT timer interrupt, we can
> - replace jiffies usage by NOW()
> - if Cyclone/HPET/ACPI is used as platform timer souce, use AC timer to
> handle overflow. 
> - if CPU has no APIC support, or PIT is used as platform timer source,
> still enable and setup PIT timer interrupt. And the timer_interrupt()
> will look like this:
>      if ( !cpu_has_apic )
>         raise_softirq(TIMER_SOFTIRQ);
>     if ( using_pit && --plt_overflow_jiffies == 0 )
>         plt_overflow();

Yep, something like that. However, you should always do PIT setup, and then
*disable* it if you don't need it after boot.

Also, I'd handle PIT overflow a bit differently. The generic overflow
handling we have in time.c can be changed to use ac timers. I would then
disable that (effectively) for PIT by having init_pit() expose a 32-bit
counter, then have the overflow handling for turning a 16-bit counter into a
32-bit counter happening behind the scenes. Don't worry about this aspect
too much though: I'm happy to clean up this part myself if you handle the
rest of the patch.

 -- Keir



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