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

[Hillf Danton]

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@xxxxxxxxxx/

> 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.