linux-kernel - Re: [RFC patch 0/5] genirq: add infrastructure 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]

Date:	Thu, 2 Oct 2008 11:02:50 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Daniel Walker <dwalker@...sta.com>
cc:	Thomas Gleixner <tglx@...utronix.de>,
	LKML <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Arjan van de Veen <arjan@...radead.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Jon Masters <jonathan@...masters.org>,
	Sven Dietrich <sdietrich@...e.de>
Subject: Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt
 handlers


On Wed, 1 Oct 2008, Daniel Walker wrote:
> > 
> > Converting an interrupt to threaded makes only sense when the handler
> > code takes advantage of it by integrating tasklet/softirq
> > functionality and simplifying the locking.
> 
> I'm not clear on your direction here.. I don't have a problem with a
> mass driver audit, which I think is what your suggesting with this patch
> set .. However, a mass audit like that would push a fully real time
> system out for quite some time..

This has nothing to do with real time, although it helps.

> 
> I also don't see a clear connection between these changes and ultimately
> removing spinlock level latency in the kernel. I realize you don't
> address that in your comments, but this is part of the initiative to
> remove spinlock level latency..

This is a completely different topic.

> 
> So with this set of changes and in terms of real time, I'm wonder your
> going with this ?

This helps with latencies and locking. With the current scheme of hardirq, 
softirq/tasklets, there are a lot of craziness with spin_locks and 
spin_lock_irqs and mutexes.

By creating an interrupt thread, we can skip the softirq/tasklet 
altogether, and this simplifies locking.

There are other cases where threaded interrupt handlers also improve 
performance. But we will get to those in due time.

-- Steve

--
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/