On 10.03.25 17:07, Moessbauer, Felix (FT RPD CED OES-DE) wrote: > Hi, > > on a 6.1.90-rt30 system we occasionally see NET_RX softirq work being > done in the ktimers thread. This could be related to running ksoftirqd > at a RT priority, but this by itself should not be problematic as PI > boosting can result in the same priority. > > Is this already a known issue? > Does it only result in delayed timer handling, or is it also > problematic from a functional PoV? > > I quickly checked the linux-next tree, but did not find any fixing > commit. > > Extract from an irq trace: > > ktimers/1-29 [001] ...s.12 ... softirq_entry: vec=3 [action=NET_RX] > ktimers/4-53 [004] ...s.12 ... softirq_entry: vec=3 [action=NET_RX] > ktimers/4-53 [004] ...s.12 ... softirq_entry: vec=3 [action=NET_RX] > BTW, the reason is because ksoftirqd and ktimerd are sharing the some softirq processing loop. run_ktimerd simply merges the so far separately tracked pending_timer_softirq into the common softirq list before calling __do_softirq, thus will also pick up any other softirq that was or is going to pend while at it. Looks at least suboptimal from a ktimerd prioritization POV. Jan -- Siemens AG, Foundational Technologies Linux Expert Center
