linux-kernel - Re: [patch 4/4] genirq: add support for threaded interrupt handlers

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 for Android: free password hash cracker in your pocket

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

Message-ID: <alpine.DEB.2.00.0902271024160.25593@gandalf.stny.rr.com>
Date:	Fri, 27 Feb 2009 10:30:37 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Arjan van de Ven <arjan@...radead.org>
cc:	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, mingo@...e.hu,
	jonathan@...masters.org
Subject: Re: [patch 4/4] genirq: add support for threaded interrupt
 handlers

On Fri, 27 Feb 2009, Arjan van de Ven wrote:

> On Fri, 27 Feb 2009 09:05:10 +0100
> Peter Zijlstra <peterz@...radead.org> wrote:
> 
> > 
> > Right, Thomas did the EHCI usb driver, the network driver you propose
> > is a tad hard since it relies on the whole network stack softirq
> > stuff. Re-working the whole net-stack to make use of threaded
> > handlers is a massive undertaking -- although I seem to remember
> > someone doing it a few years back and seeing a general performance
> > improvement, Thomas still got a link to that work?
> 
> 
> we shouldn't have to; just running the softirq handler from the irq
> thread should work, and not lose real performance.
> Sure you're not going to get a performance gain that you could get
> but it still works.
> or am I missing something?

The way softirqs are currently designed, you can not run them from
the irq thread. We discovered this (the hard way) in the preempt-rt 
kernel. The issue is that each softirq (threaded in preempt-rt, with a 
thread for every CPU. ie. net-rx/0 net-rx/1 net-rx/2 net-rx/3 for a 4 CPU 
box) is bound to a specific CPU. The design is to modify per cpu data. If 
a IRQ thread were to run the softirq code and migrate to another CPU, you 
will have very hard to debug crashes on your hands.

We also tried to bind the IRQ thread to the CPU if it were to run a 
softirq. But that too had issues. If the IRQ thread was bound to a CPU and 
a higher priority process preempted it, that IRQ handler could not migrate 
to another CPU to finish the work. Now the IRQ handler would need to wait 
for that high priority process to give up the CPU in order to continue.

The solution is to redesign the softirq code to handle migration.

-- Steve

> 
> (and esp for things like wireless drivers, that should be just fine; I
> can understand hesitation to do 10g ethernet drivers right away ;-)
> 
> 
> -- 
> Arjan van de Ven 	Intel Open Source Technology Centre
> For development, discussion and tips for power savings, 
> visit http://www.lesswatts.org
> 
--
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/