On Tue, Sep 28, 2010 at 04:51:48PM +0800, Huang Ying wrote: > +++ b/arch/x86/kernel/irq_work.c > @@ -0,0 +1,30 @@ > +/* > + * x86 specific code for irq_work > + * > + * Copyright (C) 2010 Red Hat, Inc., Peter Zijlstra <pzijlstr@xxxxxxxxxx> > + */ > + > +#include <linux/kernel.h> > +#include <linux/irq_work.h> > +#include <linux/hardirq.h> > +#include <asm/apic.h> > + > +void smp_irq_work_interrupt(struct pt_regs *regs) > +{ > + irq_enter(); > + ack_APIC_irq(); > + inc_irq_stat(apic_irq_work_irqs); > + irq_work_run(); > + irq_exit(); > +} > + > +void arch_irq_work_raise(void) > +{ > +#ifdef CONFIG_X86_LOCAL_APIC > + if (!cpu_has_apic) > + return; > + > + apic->send_IPI_self(IRQ_WORK_VECTOR); > + apic_wait_icr_idle(); > +#endif > +} So basically, CONFIG_X86_LOCAL_APIC == !HAVE_IRQ_WORK ? But IIUC, this will fallback to the timer interrupt: > @@ -1279,7 +1279,10 @@ void update_process_times(int user_tick) > run_local_timers(); > rcu_check_callbacks(cpu, user_tick); > printk_tick(); > - perf_event_do_pending(); > +#ifdef CONFIG_IRQ_WORK > + if (in_irq()) > + irq_work_run(); > +#endif > scheduler_tick(); > run_posix_cpu_timers(p); > } Then HAVE_IRQ_WORK just means that the arch supports self IPIs. So, CONFIG_IRQ_WORK doesn't need to depend on HAVE_IRQ_WORK because of the timer fallback. But archs that support self IPIs should avoid the above fallback because it bloats the timer interrupt. Perhaps CONFIG_HAVE_IRQ_WORK should be CONFIG_HAVE_IRQ_WORK_SOURCE or CONFIG_HAVE_IRQ_WORK_TRIGGER to better denote the capability. And then: config IRQ_WORK_TRIGGER depends on HAVE_IRQ_WORK_TRIGGER && IRQ_WORK default y And that would define the right condition to build the fallback in the timer interrupt. Or I am completely misunderstanding something? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html