* Keith Owens <[email protected]> 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 [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]
