| 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
| ||
|
Message-ID: <52EBFE1D.4020201@linutronix.de> Date: Fri, 31 Jan 2014 20:48:45 +0100 From: Sebastian Andrzej Siewior <bigeasy@...utronix.de> To: Steven Rostedt <rostedt@...dmis.org> CC: peterz@...radead.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 08:34 PM, Steven Rostedt wrote: > There's flags that determine when the next call should be invoked. The > irq_work_run() should return immediately if it was already done by the > arch specific call. The work wont be called twice. Well, it is called twice. It just does nothing because the list is empty & returns. > As I have worked on code that uses irq_work() I can say that we want > the arch specific interrupts. For those architectures that don't have > it will experience larger latencies for the work required. It's > basically, a "too bad" for them. 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. > But to answer your question, no we want the immediate response. > > -- Steve 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