Re: [Question] softlockup in run_timer_softirq

[John Stultz]

On Fri, Mar 3, 2023 at 2:55 AM liujian (CE) <liujian56@xxxxxxxxxx> wrote:
> From: liujian (CE)
> > From: John Stultz [mailto:jstultz@xxxxxxxxxx]
> > > On Fri, Feb 10, 2023 at 1:51 AM liujian (CE) <liujian56@xxxxxxxxxx> wrote:
> > > > Can we limit the running time of __run_timers() [2]?
> > > >
> > > > Does anyone have a good idea to solve this problem?
> > >
> > > So your patch reminds me of Peter's softirq_needs_break() logic:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/log/?
> > > h=co
> > > re/softirq
> > >
> > > Maybe it could extend that series for the timer softirq as well?
> > >
> > Thank you. Yes.
> > Base on the patchset and the extended patch for timer [1], the soft lockup
> > problem does not occur.
> >
> > By the way, I see this is a very old patchset?  Will this patchset push the main
> > line? @John @Peter
> >
> Hi, peter,
> Do you have an upstream plan for this patchset? Or other ideas.
> I want to use softirq_needs_break() to limit the runtime of timer soft interrupt handler function, wonder if this is appropriate?

My understanding is that the series was proposed but maybe caused some
regressions for the networking softirqs it was initially targeting, so
it's been stalled out.

However, if you utilize the logic to help with the timer softirq
first, that might help land the logic, and then the networking folks
can try to adapt and slowly sort out the regressions.
So I'd suggest if you have the patches working for softirqs and
showing benefit, submit them for review.

I personally was looking at the series for the block softirq (which I
got working against a 5.10 kernel), but unfortunately that code has
since been reworked to use lockless lists for its work items, it's
hard to stop if the need_break signal is set, as once we've dequeued
list entries from the list, we have to run them, as we can't easily
re-add them back in the proper list order. :/   Something I need to
re-visit eventually.

thanks
-john