On Tue, Jun 14, 2022 at 12:47 PM Sebastian Andrzej Siewior
<bigeasy@xxxxxxxxxxxxx> wrote:
>
> On 2022-06-14 12:07:48 [+0200], Arnd Bergmann wrote:
> > > So where do I put this patch to? If I remember correctly then arm64 is
> > > using this. ARM has its own thing and x86 has this change already.
> >
> > I don't see HAVE_SOFTIRQ_ON_OWN_STACK for arm, parisc, powerpc,
> > s390, sh, sparc and x86, but not arm64. I would suggest having a single
> > patch that does the same change across all architectures that don't already do
> > this, and then merging it either through tip or through my asm-generic tree.
>
> Oh. I posted the ARM bits with my other ARM patch as a mini two patch
> series a few secs before this.
Yes, I saw these, and that's why I wondered about it, because they looked
like they should not be applied independently.
> I could group this softirq change for all architectures in a single
> patch. But then powerpc didn't want the "PREEMPT_RT" annotation for the
> warning/ stack backtrace and they may not be too keen about this. So for
> powerpc I was thinking to present them all at once.
> Looking at sparc and parisc, there might be more to it than just this.
> Both were never tested while I have the missing bits for arm* and
> powerpc in my queue.
>
> Eitherway, if you want I can regroup and send you the softirq bits for
> all arches.
Yes, I think this would be good. These are still targeted for next, right?
> > > - ksoftirqd thread.
> > > - in the force-threaded interrupt after the main handler.
> > > - any time after bh-counter hits zero due local_bh_enable().
> > >
> > > The last one will cause higher task stacks.
> >
> > Does this mean it only happens when a softirq gets raised from task context
> > (which would be predictable), or also at an arbitrary time if it gets raised
> > by a non-threaded hardirq or IPI?
>
> If the softirq gets raised from non-task context (hardirq or IPI) then
> it will be deferred to ksoftirqd (and not invoked on irq-exit path).
Ok, got it, that means the stack usage is still going to be reproducible.
I wonder how common this case is in practice, but it clearly makes
sense at least from a time accounting perspective.
Arnd
