Re: [PATCH] net/sched: taprio: enforce minimum software scheduling interval

On Sun, 16 Aug 2026 22:28:47 +0800 Junjie Cao wrote:

On Fri, 14 Aug 2026, Hillf Danton wrote:

quoted

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/ (local)

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.