On Fri, Jan 31, 2014 at 09:23:52PM +0100, Sebastian Andrzej Siewior wrote:
> 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
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
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
On Fri, 31 Jan 2014 20:48:45 +0100
Sebastian Andrzej Siewior wrote:
> > 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
> >
On Fri, Jan 31, 2014 at 02:34:41PM -0500, Steven Rostedt wrote:
> On Fri, 31 Jan 2014 20:26:54 +0100
> Sebastian Andrzej Siewior wrote:
>
> > On 01/31/2014 06:57 PM, Steven Rostedt wrote:
> >
> > > In vanilla Linux, irq_work_run() is called from update_process_times()
> > > when it is called
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
On Fri, 31 Jan 2014 20:26:54 +0100
Sebastian Andrzej Siewior wrote:
> On 01/31/2014 06:57 PM, Steven Rostedt wrote:
>
> > 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
On 01/31/2014 06:57 PM, Steven Rostedt wrote:
> 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
On 01/31/2014 06:07 PM, Steven Rostedt wrote:
> The bug that I found is that if there *are* active timers, but they
> have not expired yet. Why is this a problem? Because in that case we do
Argh, right. But your patch looks also way better. After I made I was
not too happy about that amount of
On Fri, Jan 31, 2014 at 12:57:19PM -0500, Steven Rostedt wrote:
> On Fri, 31 Jan 2014 09:42:27 -0800
> "Paul E. McKenney" wrote:
>
> > On Fri, Jan 31, 2014 at 12:07:57PM -0500, Steven Rostedt wrote:
> > > On Fri, 31 Jan 2014 15:34:05 +0100
> > > Sebastian Andrzej Siewior wrote:
> > >
> > > >
On Fri, 31 Jan 2014 09:42:27 -0800
"Paul E. McKenney" wrote:
> On Fri, Jan 31, 2014 at 12:07:57PM -0500, Steven Rostedt wrote:
> > On Fri, 31 Jan 2014 15:34:05 +0100
> > Sebastian Andrzej Siewior wrote:
> >
> > > from looking at the code, it seems that the softirq is only raised (in
> > > the
On Fri, Jan 31, 2014 at 12:07:57PM -0500, Steven Rostedt wrote:
> On Fri, 31 Jan 2014 15:34:05 +0100
> Sebastian Andrzej Siewior wrote:
>
> > from looking at the code, it seems that the softirq is only raised (in
> > the !base->active_timers case) if we have also an expired timer
> >
On Fri, 31 Jan 2014 12:07:57 -0500
Steven Rostedt wrote:
> diff --git a/kernel/timer.c b/kernel/timer.c
> index 106968f..426d114 100644
> --- a/kernel/timer.c
> +++ b/kernel/timer.c
> @@ -1461,18 +1461,20 @@ void run_local_timers(void)
>* the timer softirq.
>*/
> #ifdef
On Fri, 31 Jan 2014 15:34:05 +0100
Sebastian Andrzej Siewior wrote:
> from looking at the code, it seems that the softirq is only raised (in
> the !base->active_timers case) if we have also an expired timer
> (time_before_eq() is true). This patch ensures that the timer softirq is
> also raised
from looking at the code, it seems that the softirq is only raised (in
the !base->active_timers case) if we have also an expired timer
(time_before_eq() is true). This patch ensures that the timer softirq is
also raised in the !base->active_timers && no timer expired.
Signed-off-by: Sebastian
On Fri, 31 Jan 2014 15:34:05 +0100
Sebastian Andrzej Siewior bige...@linutronix.de wrote:
from looking at the code, it seems that the softirq is only raised (in
the !base-active_timers case) if we have also an expired timer
(time_before_eq() is true). This patch ensures that the timer softirq
On Fri, 31 Jan 2014 12:07:57 -0500
Steven Rostedt rost...@goodmis.org wrote:
diff --git a/kernel/timer.c b/kernel/timer.c
index 106968f..426d114 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -1461,18 +1461,20 @@ void run_local_timers(void)
* the timer softirq.
*/
On Fri, Jan 31, 2014 at 12:07:57PM -0500, Steven Rostedt wrote:
On Fri, 31 Jan 2014 15:34:05 +0100
Sebastian Andrzej Siewior bige...@linutronix.de wrote:
from looking at the code, it seems that the softirq is only raised (in
the !base-active_timers case) if we have also an expired timer
On Fri, 31 Jan 2014 09:42:27 -0800
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Fri, Jan 31, 2014 at 12:07:57PM -0500, Steven Rostedt wrote:
On Fri, 31 Jan 2014 15:34:05 +0100
Sebastian Andrzej Siewior bige...@linutronix.de wrote:
from looking at the code, it seems that the
On Fri, Jan 31, 2014 at 12:57:19PM -0500, Steven Rostedt wrote:
On Fri, 31 Jan 2014 09:42:27 -0800
Paul E. McKenney paul...@linux.vnet.ibm.com wrote:
On Fri, Jan 31, 2014 at 12:07:57PM -0500, Steven Rostedt wrote:
On Fri, 31 Jan 2014 15:34:05 +0100
Sebastian Andrzej Siewior
On 01/31/2014 06:07 PM, Steven Rostedt wrote:
The bug that I found is that if there *are* active timers, but they
have not expired yet. Why is this a problem? Because in that case we do
Argh, right. But your patch looks also way better. After I made I was
not too happy about that amount of
On 01/31/2014 06:57 PM, Steven Rostedt wrote:
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
On Fri, 31 Jan 2014 20:26:54 +0100
Sebastian Andrzej Siewior bige...@linutronix.de wrote:
On 01/31/2014 06:57 PM, Steven Rostedt wrote:
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
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
On Fri, Jan 31, 2014 at 02:34:41PM -0500, Steven Rostedt wrote:
On Fri, 31 Jan 2014 20:26:54 +0100
Sebastian Andrzej Siewior bige...@linutronix.de wrote:
On 01/31/2014 06:57 PM, Steven Rostedt wrote:
In vanilla Linux, irq_work_run() is called from update_process_times()
when it is
On Fri, 31 Jan 2014 20:48:45 +0100
Sebastian Andrzej Siewior bige...@linutronix.de wrote:
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.
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
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
On Fri, Jan 31, 2014 at 09:23:52PM +0100, Sebastian Andrzej Siewior wrote:
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
from looking at the code, it seems that the softirq is only raised (in
the !base-active_timers case) if we have also an expired timer
(time_before_eq() is true). This patch ensures that the timer softirq is
also raised in the !base-active_timers no timer expired.
Signed-off-by: Sebastian Andrzej
30 matches
Mail list logo
