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: <52EC0658.3010205@linutronix.de>
Date:	Fri, 31 Jan 2014 21:23:52 +0100
From:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:	Peter Zijlstra <peterz@...radead.org>
CC:	Steven Rostedt <rostedt@...dmis.org>, paulmck@...ux.vnet.ibm.com,
	linux-rt-users@...r.kernel.org, linux-kernel@...r.kernel.org,
	tglx@...utronix.de, Clark Williams <williams@...hat.com>
Subject: Re: [PATCH 2/2] timer: really raise softirq if there is irq_work
 to do

On 01/31/2014 09:05 PM, Peter Zijlstra wrote:
> On Fri, Jan 31, 2014 at 08:48:45PM +0100, Sebastian Andrzej Siewior wrote:
>>
>> How "bad" is it? Is this something generic or just not getting
>> perf events fast enough out? Most users don't seem to require small
>> latencies.
> 
> I have vague memories of there being an actual perf problem if there's a
> hole between the NMI/IRQ triggering the irq_work and the interrupt
> running the work.
> 
> I should have some notes on it somewhere and an todo entry to plug the
> hole.
> 
> But note that the MCE code also uses irq_work, they really _need_ to be
> fast because the system might be crumbling under their feet.

Okay, this makes sense. What looked odd was the powerpc implementation
where they let the timer interrupt expire and call the irq_work from
the timer interrupt just before the clockevents callback is executed
(which would invoke the irq_work callback as well).

Would it be a win if we would remove the arch specific code and instead
raise the timer interrupt asap? It sure won't be a win or change for
-RT but it would allow all architectures to get irq_work done as soon
as possible in IRQ context (and out of NMI context if I understand
correct) without an arch specific implementation.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ