On Thu, 2025-02-27 at 14:43 +0100, Sebastian Andrzej Siewior wrote:
> On 2025-02-26 23:23:30 [+0100], Florian Bezdeka wrote:
> > > NAPI threads? You have RPS enabled by any chance?
> > > Would commit
> > > dad6b97702639 ("net: Allow to use SMP threads for backlog NAPI.")
> > > 80d2eefcb4c84 ("net: Use backlog-NAPI to clean up the defer_list.")
> >
> > With NAPI threads I meant the kernel threads driving the NAPI poll
> > which can be activated by "echo 1 > /sys/class/net/$device/threaded"
> >
> > RPS is build configuration wise enabled but not configured.
>
> If RPS is disabled then this might be something else.
>
> > As Felix already reported, backporting the mentioned commits to 6.1
> > would require some manual work. Simply picking all the dependencies
> > seems too much for now. Will have a look again...
>
> Can you reproduce this on a later (more recent) kernel? What are the
> steps to reproduce this?
I haven't tried that yet but after some tracing I have a much better
idea whats going on:
Our RT tuning sets ksofirqd threads to FIFO, which seems not the best
idea. I have to ask some colleagues why they thought this is necessary.
As those threads are driving the NAPI poll in my case they might run to
infinity and with that into the RT throttling - forcing CPUs to idle
with softirqs pending.
Does that make sense for you as well?
I can force the system into the same situation with threaded NAPI
enabled and assigning FIFO to the NAPI threads.
FIFO for threads driving network RX traffic doesn't seem wise. A DDoS
should be quite easy...
Florian
>
> Sebastian
