Thread (22 messages) 22 messages, 5 authors, 2014-02-03

Re: [PATCH 2/2] timer: really raise softirq if there is irq_work to do

From: Steven Rostedt <rostedt@goodmis.org>
Date: 2014-01-31 19:34:46
Also in: lkml

On Fri, 31 Jan 2014 20:26:54 +0100
Sebastian Andrzej Siewior [off-list ref] wrote:
On 01/31/2014 06:57 PM, Steven Rostedt wrote:
quoted
In vanilla Linux, irq_work_run() is called from update_process_times()
when it is called from the timer interrupt. In -rt, there's reasons we
and in vanilla Linux some architectures (like x86 or sparc to name just
a few) overwrite arch_irq_work_raise() which means they provide
their "own" interrupt like callback. That means on those architectures
irq_work_run() gets invoked twice: once via update_process_times() and
via and once the custom interface.
So my question to the original inventor of this code: Peter, do we
really need that arch specific callback? Wouldn't one be enough? Is it
that critical that it can't wait to the next timer tick?
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.

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.

But to answer your question, no we want the immediate response.

-- Steve
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help