linux-kernel - Re: [PATCH RT] Only run softirqs from the irq thread if the irq affinity is set to 1 CPU

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, 9 Aug 2007 08:38:34 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Robert de Vries <robert.h.de.vries@...il.com>
cc:	Darren Hart <dvhltc@...ibm.com>, Ingo Molnar <mingo@...e.hu>,
	RT <linux-rt-users@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	john stultz <johnstul@...ibm.com>
Subject: Re: [PATCH RT] Only run softirqs from the irq thread if the irq
 affinity is set to 1 CPU

--
On Thu, 9 Aug 2007, Robert de Vries wrote:
> On 8/8/07, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> Wouldn't a developer of a real-time system configure the system so
> that interrupts do not interfere with the real-time tasks running on a
> specific CPU?

You would think. But that's something that the Linux kernel should expect.
This can happen on a system where it's not no RT, but more soft RT (God I
hate that term). Meaning, the "optimization" of running softirqs as
threads can actually cause longer latencies to the interrupt. Since any
time an RT task preempts the IRQ while running bounded to a CPU, it will
be like masking that interrupt for the full time the RT task is running.

> In other words, is this problem not simply a misconfiguration of the system?
> I personally redirect all interrupts away from the CPU's where my
> real-time tasks run and only allow the interrupts that I want to
> handle in my application on the CPU's where I handle them so as to
> minimize latency.

This can't always be done. Say you only have two CPUS, and there's two RT
tasks that run at high priorities, on each. But it could be period that
the two don't always run at the same time. You don't want to stop
an IRQ when it gets preempted by one of the RT tasks.

So my answer to you is, no, it is not just a misconfiguration of the
system. By making an optimization, we just added a latency that would not
be there without that optimization. And it wouldn't be something that one
would expect.

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