On Tue, Feb 26, 2013 at 07:55:06PM +0100, Thomas Gleixner wrote:
> On Tue, 26 Feb 2013, Paul E. McKenney wrote:
> > On Tue, Feb 26, 2013 at 04:14:43PM +0100, Thomas Gleixner wrote:
> > >
> > > On Tue, 26 Feb 2013, Frederic Weisbecker wrote:
> > > > And what do you think about Linus's idea to move
On Tue, 26 Feb 2013, Paul E. McKenney wrote:
> On Tue, Feb 26, 2013 at 04:14:43PM +0100, Thomas Gleixner wrote:
> >
> > On Tue, 26 Feb 2013, Frederic Weisbecker wrote:
> > > And what do you think about Linus's idea to move tick_nohz_irq_exit()
> > > to do_softirq()?
> > > This sounds feasible and
On Tue, Feb 26, 2013 at 04:14:43PM +0100, Thomas Gleixner wrote:
>
> On Tue, 26 Feb 2013, Frederic Weisbecker wrote:
>
> > 2013/2/26 Thomas Gleixner :
> > > On Fri, 22 Feb 2013, Linus Torvalds wrote:
> > >> On Fri, Feb 22, 2013 at 7:06 AM, Thomas Gleixner
> > >> wrote:
> > >> >>
> > >> >> I
2013/2/26 Thomas Gleixner :
>
> On Tue, 26 Feb 2013, Frederic Weisbecker wrote:
>
>> 2013/2/26 Thomas Gleixner :
>> > On Fri, 22 Feb 2013, Linus Torvalds wrote:
>> >> On Fri, Feb 22, 2013 at 7:06 AM, Thomas Gleixner
>> >> wrote:
>> >> >>
>> >> >> I prefer to let you guys have the final word on
On Tue, 26 Feb 2013, Frederic Weisbecker wrote:
> 2013/2/26 Thomas Gleixner :
> > On Fri, 22 Feb 2013, Linus Torvalds wrote:
> >> On Fri, Feb 22, 2013 at 7:06 AM, Thomas Gleixner
> >> wrote:
> >> >>
> >> >> I prefer to let you guys have the final word on this patch. Whether you
> >> >> apply
2013/2/26 Thomas Gleixner :
> On Fri, 22 Feb 2013, Linus Torvalds wrote:
>> On Fri, Feb 22, 2013 at 7:06 AM, Thomas Gleixner wrote:
>> >>
>> >> I prefer to let you guys have the final word on this patch. Whether you
>> >> apply it or not, I fear I'll never be entirely happy either way :)
>> >>
On Fri, 22 Feb 2013, Linus Torvalds wrote:
> On Fri, Feb 22, 2013 at 7:06 AM, Thomas Gleixner wrote:
> >>
> >> I prefer to let you guys have the final word on this patch. Whether you
> >> apply it or not, I fear I'll never be entirely happy either way :)
> >> That's the sad fate of dealing with
On Fri, 22 Feb 2013, Linus Torvalds wrote:
On Fri, Feb 22, 2013 at 7:06 AM, Thomas Gleixner t...@linutronix.de wrote:
I prefer to let you guys have the final word on this patch. Whether you
apply it or not, I fear I'll never be entirely happy either way :)
That's the sad fate of dealing
2013/2/26 Thomas Gleixner t...@linutronix.de:
On Fri, 22 Feb 2013, Linus Torvalds wrote:
On Fri, Feb 22, 2013 at 7:06 AM, Thomas Gleixner t...@linutronix.de wrote:
I prefer to let you guys have the final word on this patch. Whether you
apply it or not, I fear I'll never be entirely happy
On Tue, 26 Feb 2013, Frederic Weisbecker wrote:
2013/2/26 Thomas Gleixner t...@linutronix.de:
On Fri, 22 Feb 2013, Linus Torvalds wrote:
On Fri, Feb 22, 2013 at 7:06 AM, Thomas Gleixner t...@linutronix.de
wrote:
I prefer to let you guys have the final word on this patch. Whether
2013/2/26 Thomas Gleixner t...@linutronix.de:
On Tue, 26 Feb 2013, Frederic Weisbecker wrote:
2013/2/26 Thomas Gleixner t...@linutronix.de:
On Fri, 22 Feb 2013, Linus Torvalds wrote:
On Fri, Feb 22, 2013 at 7:06 AM, Thomas Gleixner t...@linutronix.de
wrote:
I prefer to let you
On Tue, Feb 26, 2013 at 04:14:43PM +0100, Thomas Gleixner wrote:
On Tue, 26 Feb 2013, Frederic Weisbecker wrote:
2013/2/26 Thomas Gleixner t...@linutronix.de:
On Fri, 22 Feb 2013, Linus Torvalds wrote:
On Fri, Feb 22, 2013 at 7:06 AM, Thomas Gleixner t...@linutronix.de
wrote:
On Tue, 26 Feb 2013, Paul E. McKenney wrote:
On Tue, Feb 26, 2013 at 04:14:43PM +0100, Thomas Gleixner wrote:
On Tue, 26 Feb 2013, Frederic Weisbecker wrote:
And what do you think about Linus's idea to move tick_nohz_irq_exit()
to do_softirq()?
This sounds feasible and a right place
On Tue, Feb 26, 2013 at 07:55:06PM +0100, Thomas Gleixner wrote:
On Tue, 26 Feb 2013, Paul E. McKenney wrote:
On Tue, Feb 26, 2013 at 04:14:43PM +0100, Thomas Gleixner wrote:
On Tue, 26 Feb 2013, Frederic Weisbecker wrote:
And what do you think about Linus's idea to move
On Sat, Feb 23, 2013 at 10:21 AM, Frederic Weisbecker
wrote:
>
> But tick_nohz_irq_exit() may trigger the timer softirq itself.
Suggestion: merge it with the whole softirq handler.
The softirq code *already* knows about the whole "oops, one softirq
may trigger another" issue, and has a loop -
On Fri, Feb 22, 2013 at 01:08:17PM -0800, Linus Torvalds wrote:
> On Fri, Feb 22, 2013 at 7:06 AM, Thomas Gleixner wrote:
> >>
> >> I prefer to let you guys have the final word on this patch. Whether you
> >> apply it or not, I fear I'll never be entirely happy either way :)
> >> That's the sad
On Fri, Feb 22, 2013 at 01:08:17PM -0800, Linus Torvalds wrote:
On Fri, Feb 22, 2013 at 7:06 AM, Thomas Gleixner t...@linutronix.de wrote:
I prefer to let you guys have the final word on this patch. Whether you
apply it or not, I fear I'll never be entirely happy either way :)
That's the
On Sat, Feb 23, 2013 at 10:21 AM, Frederic Weisbecker
fweis...@gmail.com wrote:
But tick_nohz_irq_exit() may trigger the timer softirq itself.
Suggestion: merge it with the whole softirq handler.
The softirq code *already* knows about the whole oops, one softirq
may trigger another issue, and
On Fri, Feb 22, 2013 at 7:06 AM, Thomas Gleixner wrote:
>>
>> I prefer to let you guys have the final word on this patch. Whether you
>> apply it or not, I fear I'll never be entirely happy either way :)
>> That's the sad fate of dealing with circular dependencies...
>
> plus the butt ugly
On Fri, 22 Feb 2013, Frederic Weisbecker wrote:
> On Fri, Feb 22, 2013 at 03:33:51PM +0100, Thomas Gleixner wrote:
> > The minimal extra check at the end of irq_exit() is way better than
> > any other special cased workaround and the softirq stuff is really the
> > only thing which needs to be
On Fri, Feb 22, 2013 at 03:33:51PM +0100, Thomas Gleixner wrote:
> On Fri, 22 Feb 2013, Frederic Weisbecker wrote:
> > The irq code is run under HARDIRQ_OFFSET preempt offset until
> > we reach the softirq code. Then it's substracted, leaving the
> > preempt count to 0, whether we have pending
On Fri, 22 Feb 2013, Frederic Weisbecker wrote:
> The irq code is run under HARDIRQ_OFFSET preempt offset until
> we reach the softirq code. Then it's substracted, leaving the
> preempt count to 0, whether we have pending softirqs or not.
>
> Afterward, if we have softirqs to run, we'll run them
On Fri, 22 Feb 2013, Frederic Weisbecker wrote:
The irq code is run under HARDIRQ_OFFSET preempt offset until
we reach the softirq code. Then it's substracted, leaving the
preempt count to 0, whether we have pending softirqs or not.
Afterward, if we have softirqs to run, we'll run them under
On Fri, Feb 22, 2013 at 03:33:51PM +0100, Thomas Gleixner wrote:
On Fri, 22 Feb 2013, Frederic Weisbecker wrote:
The irq code is run under HARDIRQ_OFFSET preempt offset until
we reach the softirq code. Then it's substracted, leaving the
preempt count to 0, whether we have pending softirqs
On Fri, 22 Feb 2013, Frederic Weisbecker wrote:
On Fri, Feb 22, 2013 at 03:33:51PM +0100, Thomas Gleixner wrote:
The minimal extra check at the end of irq_exit() is way better than
any other special cased workaround and the softirq stuff is really the
only thing which needs to be taken care
On Fri, Feb 22, 2013 at 7:06 AM, Thomas Gleixner t...@linutronix.de wrote:
I prefer to let you guys have the final word on this patch. Whether you
apply it or not, I fear I'll never be entirely happy either way :)
That's the sad fate of dealing with circular dependencies...
plus the butt
The irq code is run under HARDIRQ_OFFSET preempt offset until
we reach the softirq code. Then it's substracted, leaving the
preempt count to 0, whether we have pending softirqs or not.
Afterward, if we have softirqs to run, we'll run them under
the SOFTIRQ_OFFSET then set the preempt offset back
The irq code is run under HARDIRQ_OFFSET preempt offset until
we reach the softirq code. Then it's substracted, leaving the
preempt count to 0, whether we have pending softirqs or not.
Afterward, if we have softirqs to run, we'll run them under
the SOFTIRQ_OFFSET then set the preempt offset back
28 matches
Mail list logo
