From: Hillf Danton <hdanton@sina.com>
To: Junjie Cao <junjie.cao@intel.com>
Cc: Uladzislau Zhauniarovich <uladzislau.zhauniarovich@gmail.com>,
Vinicius Costa Gomes <vinicius.gomes@intel.com>,
Eric Dumazet <edumazet@google.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
syzbot+19d01f6082ec61dd45b2@syzkaller.appspotmail.com
Subject: Re: [PATCH] net/sched: taprio: enforce minimum software scheduling interval
Date: Mon, 17 Aug 2026 08:35:13 +0800 [thread overview]
Message-ID: <20260817003514.1241-1-hdanton@sina.com> (raw)
In-Reply-To: <20260816142847.227167-1-junjie.cao@intel.com>
On Sun, 16 Aug 2026 22:28:47 +0800 Junjie Cao wrote:
> On Fri, 14 Aug 2026, Hillf Danton wrote:
> > Better if you specify why interval like 2us is ruled out.
>
> The yardstick is the service cost of one expiry. On a release build I
> see ~5.1M local timer interrupts in 5s on the owning CPU for a 700ns
> single-entry schedule on veth, so the whole per-expiry service path is
> around a microsecond; Uladzislau estimated ~10us per invocation on the
> syzbot debug config earlier in the moderation thread. A 2us interval
> still livelocks a debug build, and on a release build it pins a
> permanent ~500k irqs/s on one CPU. 100us keeps margin above the
> debug-config cost.
>
The 2us interval survived the syzbot test [10].
[10] Subject: Re: [syzbot] [mm?] INFO: rcu detected stall in exit_to_user_mode_loop
https://lore.kernel.org/lkml/68885247.a00a0220.b12ec.00c8.GAE@google.com/
> One more thing that came out of testing this: the floor only covers
> half of the problem. A valid schedule that falls behind replays its
> whole backlog one hrtimer expiry at a time. With a 4x200us schedule
> and CLOCK_TAI stepped forward 72h (think ptp4l's first big step, or a
> VM pause) I get an RCU stall with the owning CPU stuck in hrtimer
> expiry processing, and no admission check can catch that; syzbot's
> reports show the same stall with advance_sched() on the stack. A
> bounded catch-up in advance_sched() fixes it. Conversely, catch-up
> alone doesn't help the storm case: the 700ns schedule is still
> admitted and sustains ~1M irqs/s.
>
> I have both halves ready as a series - a bounded catch-up in
> advance_sched() plus this patch with the exemption folded in - tested
> by syzbot against both reproducer buckets on net.git dd057113ac7b,
> with a tc-testing case. I plan to post it in a day, keeping your
> Signed-off-by on this one, unless you'd prefer to respin it yourself.
>
The guys on the cc list know I hate SOB because cc is enough.
prev parent reply other threads:[~2026-08-17 0:35 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 2:15 [PATCH] net/sched: taprio: enforce minimum software scheduling interval syzbot
2026-08-14 16:13 ` Simon Horman
2026-08-16 14:28 ` Junjie Cao
2026-08-17 0:35 ` Hillf Danton [this message]
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=20260817003514.1241-1-hdanton@sina.com \
--to=hdanton@sina.com \
--cc=edumazet@google.com \
--cc=junjie.cao@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=syzbot+19d01f6082ec61dd45b2@syzkaller.appspotmail.com \
--cc=uladzislau.zhauniarovich@gmail.com \
--cc=vinicius.gomes@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox