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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20090227001532.5dd84c2d.akpm@linux-foundation.org>
Date:	Fri, 27 Feb 2009 00:15:32 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, rostedt@...dmis.org,
	jonathan@...masters.org
Subject: Re: [patch 4/4] genirq: add support for threaded interrupt handlers

On Fri, 27 Feb 2009 09:05:10 +0100 Peter Zijlstra <peterz@...radead.org> wrote:

> > What is the plan (if any) for integrating threaded interrupt handlers
> > with softirqs?  I guess things will "just work" at present, and
> > threaded softirqs happen in a later patch?
> 
> Thing is, stuff that now needs softirq could be directly done in the
> threaded handler, ergo softirq usage should decline (and hopefully
> disappear all together - famous last words).
> 
> We only use softirq/workqueues/tasklets because we need a preemptible
> environment, which the traditional irq handler didn't provide. With
> threaded interrupts we do have that.

ah.  I was specifically thinking of net/core/dev.c.  That's our
heaviest user of interrupts and softirqs, I expect?

> > I'd have thought that the softirq latency could get quite a bit worse
> > with this proposed threaded-irq patch?
> 
> Due to the propagation of wakeups? irq wakes up thread, thread wakes up
> softirq, etc?
> 
> Yes it would, another good reason to simply use the threaded handler to
> do whatever the softirq used to do, no?
> 
> > I suppose we could just run the softirq handlers directly after running
> > the irq handler, from the IRQ thread.  Rather than having to poke
> > softirqd all the time?
> 
> One could I suppose, except that softirqs are per-cpu and threaded
> interrupts are not, so they don't map that well. We played around with
> this on preempt-rt for a while, but it kept on breaking stuff.
> 
> Its all a lot more tracktable when you get to change the driver, as you
> have more information.
> 
> > Thwap me if this was all in whatever-changelog-that-was as well ;)
> 
> Hehe, no you got some good points this time around ;-)
> 
> > Also...
> > 
> > Given that this threaded-irq code appears to be new and not very tested
> > in -rt, I think it would be a good idea to convert some popular drivers
> > (e1000/e1000e) so that the core code gets a good thrashing before we
> > merge it.
> 
> 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

oh.  That rather changes the perspective on the whole exercise.  hrm.

> -- 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?
> 
> But yes, it would be prudent to convert a few frequently used driver to
> this model before merging I suppose.
--
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/