RE: [RFC][PATCH] i386 x86-64 Eliminate Local APIC timer interrupt

From: Pallipadi, Venkatesh
Date: Fri Apr 29 2005 - 21:45:28 EST

>-----Original Message-----
>From: Zwane Mwaikambo [mailto:zwane@xxxxxxxxxxxxxxxx]
>Sent: Friday, April 29, 2005 6:13 PM
>To: Pallipadi, Venkatesh
>Cc: Andrew Morton; Linus Torvalds; mingo@xxxxxxx;
>linux-kernel; Shah, Rajesh; John Stultz; Andi Kleen; Mallick, Asit K
>Subject: Re: [RFC][PATCH] i386 x86-64 Eliminate Local APIC
>timer interrupt
>On Fri, 29 Apr 2005, Venkatesh Pallipadi wrote:
>> Proposed Fix:
>> Attached is a prototype patch, that tries to eliminate the
>dependency on
>> local APIC timer for update_process_times(). The patch gets
>rid of Local APIC
>> timer altogether. We use the timer interrupt (IRQ 0) configured in
>> broadcast mode in IOAPIC instead (Doesn't work with 8259).
>> As changing anything related to basic timer interrupt is a
>little bit risky,
>> I have a boot parameter currently ("useapictimer") to switch
>back to original
>> local APIC timer way of doing things.
>I'm rather reluctant to advocate the broadcast scheme as i can see it
>breaking on a lot of systems, e.g. SMP systems which use i8259 (as you
>noted), IBM x440 and ES7000. If anything the default mode
>should be APIC
>timer and have a parameter to disable it.

The patch as it is should handle 8259 case using the regular APIC timer.
It only adds broadcast when IOAPIC is used for timer interrupt.

And if broadcast doesn't work on IBM x440 and ES7000, it can easily
be handled by sub-arch, to use local APIC.

> Regarding things like variable
>timer ticks, reprogramming the PIT is slow, and using it
>extensively for
>such sounds like a step in the wrong direction.

Variable tick should come into picture only when system is totally idle
(for a long time). The algorithm that change ticks should handle the
trade-off between frequent HZ interrupt when system is idle and overhead
Of reprogramming PIT/HPET. And variable HZ is already changing PIT if I
Remember correctly. This patch doesn't add any complexity there.

> Is this feature/bug going to proliferate amongst newer processor
> local APICs?

This APIC timer stopping in C3 will affect all CPUs that have C3 or
deeper state.

Although I agree that changing the things like timer interrupt is like
walking on a landmine, given all different kind of hardware present,
in general this seems simplify things related to timer interrupts.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at