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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 29 Sep 2010 15:11:02 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	huang ying <huang.ying.caritas@...il.com>
Cc:	Huang Ying <ying.huang@...el.com>, Ingo Molnar <mingo@...e.hu>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>,
	paulus <paulus@...ba.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andi Kleen <andi@...stfloor.org>,
	dhowells <dhowells@...hat.com>,
	Russell King <rmk@....linux.org.uk>,
	Kyle McMartin <kyle@...artin.ca>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	davem <davem@...emloft.net>,
	Linux-Arch <linux-arch@...r.kernel.org>
Subject: Re: [PATCH -tip -v6] irq_work: generic hard-irq context callbacks

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@...il.com> 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@...hat.com>
> >> + */
> >> +
> >> +#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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/