From: Thomas Gleixner <tglx@linutronix.de>
To: Jakub Kicinski <kuba@kernel.org>, peterz@infradead.org
Cc: jstultz@google.com, edumazet@google.com, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>
Subject: Re: [PATCH 2/3] softirq: avoid spurious stalls due to need_resched()
Date: Fri, 03 Mar 2023 16:18:03 +0100 [thread overview]
Message-ID: <87jzzxkgno.ffs@tglx> (raw)
In-Reply-To: <87r0u6j721.ffs@tglx>
Jakub!
On Fri, Mar 03 2023 at 14:30, Thomas Gleixner wrote:
> On Thu, Dec 22 2022 at 14:12, Jakub Kicinski wrote:
> But without the sched_clock() changes the actual defer time depends on
> HZ and the point in time where limit is set. That means it ranges from 0
> to 1/HZ, i.e. the 2ms defer time ends up with close to 10ms on HZ=100 in
> the worst case, which perhaps explains the 8ms+ stalls you are still
> observing. Can you test with that sched_clock change applied, i.e. the
> first two commits from
>
> git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git core/softirq
>
> 59be25c466d9 ("softirq: Use sched_clock() based timeout")
> bd5a5bd77009 ("softirq: Rewrite softirq processing loop")
>
> whether that makes a difference? Those two can be applied with some
> minor polishing. The rest of that series is broken by f10020c97f4c
> ("softirq: Allow early break").
WHile staring I noticed that the current jiffies based time limit
handling has the exact same problem. For HZ=100 and HZ=250
MAX_SOFTIRQ_TIME resolves to 1 jiffy. So the window is between 0 and
1/HZ. Not really useful.
Thanks,
tglx
next prev parent reply other threads:[~2023-03-03 15:18 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-22 22:12 [PATCH 0/3] softirq: uncontroversial change Jakub Kicinski
2022-12-22 22:12 ` [PATCH 1/3] softirq: rename ksoftirqd_running() -> ksoftirqd_should_handle() Jakub Kicinski
2022-12-22 22:12 ` [PATCH 2/3] softirq: avoid spurious stalls due to need_resched() Jakub Kicinski
2023-01-31 22:32 ` Jakub Kicinski
2023-03-03 13:30 ` Thomas Gleixner
2023-03-03 15:18 ` Thomas Gleixner [this message]
2023-03-03 21:31 ` Jakub Kicinski
2023-03-03 22:37 ` Paul E. McKenney
2023-03-03 23:25 ` Dave Taht
2023-03-04 1:14 ` Paul E. McKenney
2023-03-03 23:36 ` Paul E. McKenney
2023-03-03 23:44 ` Jakub Kicinski
2023-03-04 1:25 ` Paul E. McKenney
2023-03-04 1:39 ` Jakub Kicinski
2023-03-04 3:11 ` Paul E. McKenney
2023-03-04 20:48 ` Paul E. McKenney
2023-03-05 20:43 ` Thomas Gleixner
2023-03-05 22:42 ` Paul E. McKenney
2023-03-05 23:00 ` Frederic Weisbecker
2023-03-06 4:30 ` Paul E. McKenney
2023-03-06 11:22 ` Frederic Weisbecker
2023-03-06 9:13 ` David Laight
2023-03-06 11:57 ` Frederic Weisbecker
2023-03-06 14:57 ` Paul E. McKenney
2023-03-07 0:51 ` Jakub Kicinski
2022-12-22 22:12 ` [PATCH 3/3] softirq: don't yield if only expedited handlers are pending Jakub Kicinski
2023-01-09 9:44 ` Peter Zijlstra
2023-01-09 10:16 ` Eric Dumazet
2023-01-09 19:12 ` Jakub Kicinski
2023-03-03 11:41 ` Thomas Gleixner
2023-03-03 14:17 ` Thomas Gleixner
2023-04-20 17:24 ` [PATCH 0/3] softirq: uncontroversial change Paolo Abeni
2023-04-20 17:41 ` Eric Dumazet
2023-04-20 20:23 ` Paolo Abeni
2023-04-21 2:48 ` Jason Xing
2023-04-21 9:33 ` Paolo Abeni
2023-04-21 9:46 ` Jason Xing
2023-05-09 19:56 ` [tip: irq/core] Revert "softirq: Let ksoftirqd do its job" tip-bot2 for Paolo Abeni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87jzzxkgno.ffs@tglx \
--to=tglx@linutronix.de \
--cc=edumazet@google.com \
--cc=jstultz@google.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.