Messages in this thread | | | Date | Thu, 29 Jun 2006 22:17:52 +0200 | From | Ingo Molnar <> | Subject | Re: i386 IPI handlers running with hardirq_count == 0 |
| |
* Keith Owens <kaos@ocs.com.au> wrote:
> My question has nothing to do with NMI. I am querying inconsistent > behaviour amongst normal IPIs, this list :- > > i386 function irq_enter? > smp_apic_timer_interrupt yes > smp_call_function_interrupt yes > smp_error_interrupt yes > smp_invalidate_interrupt no - why > smp_reschedule_interrupt no (does not need it) > smp_spurious_interrupt yes > smp_thermal_interrupt yes > > x86_64 function irq_enter? > mce_threshold_interrupt yes > smp_apic_timer_interrupt yes > smp_call_function_interrupt yes > smp_error_interrupt yes > smp_invalidate_interrupt no - why > smp_reschedule_interrupt no (does not need it) > smp_spurious_interrupt yes > smp_thermal_interrupt yes
irq_enter() is mostly just for the purpose of in_interrupt()/in_irq() to work as expected, not much else. [also the timer code assumes that update_process_times() is called in a HARDIRQ_OFFSET elevated context, so the apic timer IRQ needs irq_enter() too.] The smp_invalidate_interrupt() and smp_reschedule_interrupt() is performance-critical and they dont need irq_enter()/irq_exit().
Since smp_call_function_interrupt() can be called with driver-supplied function vectors, it's best to keep the irq_enter()/exit there. [for example mm/slab.c has some in_interrupt() sanity checks.] Obviously do_IRQ() itself needs irq_enter()/exit() too - plus the APIC timer irq as mentioned above.
Otherwise, the rest of the SMP functions technically dont need irq_enter()/irq_exit(). [i.e. threshold, error, spurious and thermal] We could remove it from them.
Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |