On Wed, Sep 25, 2013 at 06:55:47AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2013-09-24 at 15:56 +0200, Frederic Weisbecker wrote:
> > On Tue, Sep 24, 2013 at 02:42:57PM +1000, Benjamin Herrenschmidt wrote:
> > > On Tue, 2013-09-24 at 04:44 +0200, Frederic Weisbecker wrote:
> > > > So the safe
On Tue, 2013-09-24 at 15:27 -0400, Chris Metcalf wrote:
> > It's hard to tell with gcc ... the best I've had so far as an option was
> > something that would mark my per-cpu register (r13) *itself* as clobbered...
>
> Well, as I said above, that would be better, but it requires providing an
> alte
On Tue, 2013-09-24 at 15:56 +0200, Frederic Weisbecker wrote:
> On Tue, Sep 24, 2013 at 02:42:57PM +1000, Benjamin Herrenschmidt wrote:
> > On Tue, 2013-09-24 at 04:44 +0200, Frederic Weisbecker wrote:
> > > So the safest way to fix this is to unconditionally call do_softirq()
> > > from irq_exit()
On 9/23/2013 4:57 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2013-09-23 at 13:59 -0400, Chris Metcalf wrote:
>> We just came up against this on tilegx with a customer bug report in a
>> PREEMPT environment. On tile, %tp is a GPR that points to the percpu area.
>> The following seems to be the rig
On Tue, Sep 24, 2013 at 02:42:57PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2013-09-24 at 04:44 +0200, Frederic Weisbecker wrote:
> > So the safest way to fix this is to unconditionally call do_softirq()
> > from irq_exit().
> > A performance penalty may come along but safety primes.
> >
> >
On Tue, 2013-09-24 at 10:21 +0200, Peter Zijlstra wrote:
> > I don't see how that relates to the above though...
>
> It was a comment on the increase of per-cpu usage in generic code.
Oh I see. Ok, but some things are intrinsically per-task so if you use
per-cpu in that case you end up context sw
On Tue, Sep 24, 2013 at 06:16:53PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2013-09-24 at 10:04 +0200, Peter Zijlstra wrote:
> > On Tue, Sep 24, 2013 at 11:52:07AM +1000, Benjamin Herrenschmidt wrote:
> > > So if that holds, we have a solid way to do per-cpu. On one side, I tend
> > > to thin
On Tue, 2013-09-24 at 10:04 +0200, Peter Zijlstra wrote:
> On Tue, Sep 24, 2013 at 11:52:07AM +1000, Benjamin Herrenschmidt wrote:
> > So if that holds, we have a solid way to do per-cpu. On one side, I tend
> > to think that r13 being task/thread/thread_info is probably a better
> > overall choice
On Tue, Sep 24, 2013 at 11:52:07AM +1000, Benjamin Herrenschmidt wrote:
> So if that holds, we have a solid way to do per-cpu. On one side, I tend
> to think that r13 being task/thread/thread_info is probably a better
> overall choice, I'm worried that going in a different direction than x86
> mean
On Tue, 2013-09-24 at 04:44 +0200, Frederic Weisbecker wrote:
> So the safest way to fix this is to unconditionally call do_softirq()
> from irq_exit().
> A performance penalty may come along but safety primes.
>
> We should probably do that and work on longer term solutions (Kconfig
> based arch
On Mon, Sep 23, 2013 at 02:40:34PM +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2013-09-22 at 07:45 +1000, Benjamin Herrenschmidt wrote:
> > What I *can* do that would help I suppose would be to switch to the irq
> > stack before irq_enter/exit which would at least mean that softirq would
> > run
On Mon, 2013-09-23 at 18:19 -0700, Linus Torvalds wrote:
> On Mon, Sep 23, 2013 at 5:10 PM, Benjamin Herrenschmidt
> wrote:
> >
> > BTW, that boils down to a choice between using r13 as either a TLS for
> > current or current_thread_info, or as a per-cpu pointer, which one is
> > the most performa
On Mon, Sep 23, 2013 at 5:10 PM, Benjamin Herrenschmidt
wrote:
>
> BTW, that boils down to a choice between using r13 as either a TLS for
> current or current_thread_info, or as a per-cpu pointer, which one is
> the most performance critical ?
I think you can tune most of the architecture setup t
On Sun, 2013-09-22 at 15:22 -0700, Linus Torvalds wrote:
> - use %r13 for the per-thread thread-info pointer instead. A
> per-thread pointer is *not* volatile like the per-cpu base is.
.../...
> Alternatively, make %r13 point to the percpu side, but make sure that
> you always use an asm access
On Mon, 2013-09-23 at 13:59 -0400, Chris Metcalf wrote:
> We just came up against this on tilegx with a customer bug report in a
> PREEMPT environment. On tile, %tp is a GPR that points to the percpu area.
> The following seems to be the right abstraction -- though I'd also argue
> that letting ba
On 9/22/2013 6:23 PM, Linus Torvalds wrote:
> Alternatively, make %r13 point to the percpu side, but make sure that
> you always use an asm accessor to fetch the value. In particular, I
> think you need to make __my_cpu_offset be an inline asm that fetches
> %r13 into some other register. Otherwise
From: Benjamin Herrenschmidt
Date: Mon, 23 Sep 2013 14:40:34 +1000
> Heads up guys: i386 and sparc at least seem to need the same
> treatment.
I'll take a look thanks for the heads up.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord.
On Sun, 2013-09-22 at 07:45 +1000, Benjamin Herrenschmidt wrote:
> What I *can* do that would help I suppose would be to switch to the irq
> stack before irq_enter/exit which would at least mean that softirq would
> run from the top of the irq stack which is better than the current
> situation.
>
On Sun, 2013-09-22 at 15:22 -0700, Linus Torvalds wrote:
> On Sun, Sep 22, 2013 at 2:56 PM, Benjamin Herrenschmidt
> wrote:
> > On Sun, 2013-09-22 at 18:24 +0200, Peter Zijlstra wrote:
> >>
> >> We use a segment offset. Something like:
> >>
> >> inc %gs:var;
> >>
> >
> > And gcc makes no stupid
On Sun, Sep 22, 2013 at 2:56 PM, Benjamin Herrenschmidt
wrote:
> On Sun, 2013-09-22 at 18:24 +0200, Peter Zijlstra wrote:
>>
>> We use a segment offset. Something like:
>>
>> inc %gs:var;
>>
>
> And gcc makes no stupid assumptions that this gs doesn't change ? That's
> the main problem we have w
On Sun, 2013-09-22 at 10:47 -0700, H. Peter Anvin wrote:
> On 09/22/2013 09:24 AM, Peter Zijlstra wrote:
> >
> > As to the problem of GCC moving r13 about, some archs have some
> > exceptions in the register allocator and leave some registers alone.
> > IIRC MIPS has this and uses one of those (is
On Sun, 2013-09-22 at 18:24 +0200, Peter Zijlstra wrote:
> On Sun, Sep 22, 2013 at 02:41:01PM +1000, Benjamin Herrenschmidt wrote:
> > On Sun, 2013-09-22 at 14:39 +1000, Benjamin Herrenschmidt wrote:
> > > How do you do your per-cpu on x86 ?
>
> We use a segment offset. Something like:
>
> inc
On 09/22/2013 09:24 AM, Peter Zijlstra wrote:
>
> As to the problem of GCC moving r13 about, some archs have some
> exceptions in the register allocator and leave some registers alone.
> IIRC MIPS has this and uses one of those (istr there's 2) for the
> per cpu base address.
>
You can force gcc
On Sun, Sep 22, 2013 at 02:41:01PM +1000, Benjamin Herrenschmidt wrote:
> On Sun, 2013-09-22 at 14:39 +1000, Benjamin Herrenschmidt wrote:
> > How do you do your per-cpu on x86 ?
We use a segment offset. Something like:
inc %gs:var;
would be a per-cpu increment. The actual memory location use
On Sun, 2013-09-22 at 14:39 +1000, Benjamin Herrenschmidt wrote:
> How do you do your per-cpu on x86 ? On powerpc we struggle because we
> try to dedicate a register (r13) to this PACA (the per-cpu offset hangs
> off it), but we constantly run into issues where gcc copies r13 to
> another register
On Sat, 2013-09-21 at 19:01 -0700, H. Peter Anvin wrote:
> On 09/21/2013 02:45 PM, Benjamin Herrenschmidt wrote:
> >
> > I really don't like the "larger" irq stack ... probably because I can't
> > make it work easily :-) See my previous comment about how we get to
> > thread_info on ppc.
> >
>
>
On 09/21/2013 02:45 PM, Benjamin Herrenschmidt wrote:
>
> I really don't like the "larger" irq stack ... probably because I can't
> make it work easily :-) See my previous comment about how we get to
> thread_info on ppc.
>
For the record, I intend to remove thread_info from the stack on x86 and
On Sun, Sep 22, 2013 at 07:45:01AM +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2013-09-21 at 13:58 -0500, Frederic Weisbecker wrote:
>
> > Now certainly what needs to be fixed then is archs that don't have
> > __ARCH_IRQ_EXIT_IRQS_DISABLED
> > or archs that have any other significant opportunit
On Sat, 2013-09-21 at 13:58 -0500, Frederic Weisbecker wrote:
> Now certainly what needs to be fixed then is archs that don't have
> __ARCH_IRQ_EXIT_IRQS_DISABLED
> or archs that have any other significant opportunity to nest interrupt.
Interesting. I notice we don't define it on powerpc but we d
2013/9/20 Linus Torvalds :
> On Fri, Sep 20, 2013 at 9:26 AM, Frederic Weisbecker
> wrote:
>>
>> Now just for clarity, what do we then do with inline sofirq executions: on
>> local_bh_enable()
>> for example, or explicit calls to do_softirq() other than irq exit?
>
> If we do a softirq because i
* Linus Torvalds wrote:
> On Fri, Sep 20, 2013 at 9:26 AM, Frederic Weisbecker
> wrote:
> >
> > Now just for clarity, what do we then do with inline sofirq
> > executions: on local_bh_enable() for example, or explicit calls to
> > do_softirq() other than irq exit?
>
> If we do a softirq bec
On Fri, 2013-09-20 at 13:11 +0200, Peter Zijlstra wrote:
> On Fri, Sep 20, 2013 at 01:03:17PM +0200, Thomas Gleixner wrote:
> > On Thu, 19 Sep 2013, Linus Torvalds wrote:
> >
> > > On Thu, Sep 19, 2013 at 2:51 PM, Frederic Weisbecker
> > > wrote:
> > > >
> > > > It fixes stacks overruns reported
On Fri, 2013-09-20 at 11:26 -0500, Frederic Weisbecker wrote:
> Looks good to me.
>
> Now just for clarity, what do we then do with inline sofirq executions: on
> local_bh_enable()
> for example, or explicit calls to do_softirq() other than irq exit?
We cannot make the irq stack larger than the
On Fri, Sep 20, 2013 at 9:26 AM, Frederic Weisbecker wrote:
>
> Now just for clarity, what do we then do with inline sofirq executions: on
> local_bh_enable()
> for example, or explicit calls to do_softirq() other than irq exit?
If we do a softirq because it was pending and we did a
"local_bh_en
On Fri, Sep 20, 2013 at 07:30:14PM +0200, Thomas Gleixner wrote:
> On Fri, 20 Sep 2013, Frederic Weisbecker wrote:
>
> > Now just for clarity, what do we then do with inline sofirq
> > executions: on local_bh_enable() for example, or explicit calls to
> > do_softirq() other than irq exit? Should
On Fri, 20 Sep 2013, Frederic Weisbecker wrote:
> Now just for clarity, what do we then do with inline sofirq
> executions: on local_bh_enable() for example, or explicit calls to
> do_softirq() other than irq exit? Should we keep the current switch
> to a different softirq stack? If we have a gen
On Fri, Sep 20, 2013 at 01:03:17PM +0200, Thomas Gleixner wrote:
> On Thu, 19 Sep 2013, Linus Torvalds wrote:
>
> > On Thu, Sep 19, 2013 at 2:51 PM, Frederic Weisbecker
> > wrote:
> > >
> > > It fixes stacks overruns reported by Benjamin Herrenschmidt:
> > > http://lkml.kernel.org/r/1378330796.4
On Fri, Sep 20, 2013 at 01:03:17PM +0200, Thomas Gleixner wrote:
> On Thu, 19 Sep 2013, Linus Torvalds wrote:
>
> > On Thu, Sep 19, 2013 at 2:51 PM, Frederic Weisbecker
> > wrote:
> > >
> > > It fixes stacks overruns reported by Benjamin Herrenschmidt:
> > > http://lkml.kernel.org/r/1378330796.4
On Thu, 19 Sep 2013, Linus Torvalds wrote:
> On Thu, Sep 19, 2013 at 2:51 PM, Frederic Weisbecker
> wrote:
> >
> > It fixes stacks overruns reported by Benjamin Herrenschmidt:
> > http://lkml.kernel.org/r/1378330796.4321.50.camel%40pasglop
>
> So I don't really dislike this patch-series, but is
On Thu, 2013-09-19 at 19:02 -0500, Linus Torvalds wrote:
> On Thu, Sep 19, 2013 at 2:51 PM, Frederic Weisbecker
> wrote:
> >
> > It fixes stacks overruns reported by Benjamin Herrenschmidt:
> > http://lkml.kernel.org/r/1378330796.4321.50.camel%40pasglop
>
> So I don't really dislike this patch-s
On Thu, Sep 19, 2013 at 2:51 PM, Frederic Weisbecker wrote:
>
> It fixes stacks overruns reported by Benjamin Herrenschmidt:
> http://lkml.kernel.org/r/1378330796.4321.50.camel%40pasglop
So I don't really dislike this patch-series, but isn't "irq_exit()"
(which calls the new softirq_on_stack()) a
Thomas,
Please consider this patchset for pulling from:
git://github.com/fweisbec/linux-dynticks.git
irq/core-v2
HEAD: 539b9cde35b473483c722de110133cd757015947
It fixes stacks overruns reported by Benjamin Herrenschmidt:
http://lkml.kernel.org/r/1378330796.4321.50.camel%40pasglop
And P
42 matches
Mail list logo
