Thanks for the comments.
Keir Fraser wrote:
> On 7/4/08 10:18, "Yu, Ke" <ke.yu@xxxxxxxxx> wrote:
>
>> 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).
Agree. Will do this way.
>
>> 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!
Yes. AC timer expire period will be half of the actual overflow period.
Thanks for reminder.
>
>> 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
Not quite understand this point, could you please elaborate more? And
surely I am happy to leave this for you to clean up :)
The logic in my mind is as follow, just want to make sure it leave
enough space for you to refine PIT handling logic.
1. when xen is booting, setup PIT timer interrupt
2. if Cyclone/HPET/ACPI PM timer is clock source, setup AC timer for the
overflow handling
3. if not using PIT and CPU has APIC, then disable PIT timer interrupt.
Best Regards
Ke
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home