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

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

 



 

>-----Original Message-----
>From: Zwane Mwaikambo [mailto:[email protected]] 
>Sent: Friday, April 29, 2005 6:13 PM
>To: Pallipadi, Venkatesh
>Cc: Andrew Morton; Linus Torvalds; [email protected]; 
>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.

Thanks,
Venki
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux