Re: [PATCH -tip -v6] irq_work: generic hard-irq context callbacks

[Frederic Weisbecker]

On Wed, Sep 29, 2010 at 04:29:52PM +0800, huang ying wrote:
> Hi, Frederic,
> 
> On Tue, Sep 28, 2010 at 11:56 PM, Frederic Weisbecker
> <fweisbec@xxxxxxxxx> wrote:
> > 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:
> 
> If !CONFIG_X86_LOCAL_APIC or !cpu_has_apic, this will fallback to the
> timer interrupt.


Ah right, there is cpu_has_apic, so we may need the dynamic and adaptive
fallback. May be cpu_has_apic only appears on very particular configs though,
so that we can narrow down this situation statically?


 
> >> @@ -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.
> 
> HAVE_IRQ_WORK means IRQ_WORK is supported on the architecture, it has
> nothing to do with self IPIs.


Ok, but IRQ_WORK is always supported on the architecture because of
the fallback. It seems that archs enable HAVE_IRQ_WORK when they find
an optimization (self IPIs in x86, other shortcuts in other archs), but
these optimizations never change the core code anyway, right?
It would have been nice to avoid building the fallback when the archs can
already manage the path by themselves.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/