On 2025-03-10 16:07:03 [+0000], MOESSBAUER, Felix 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 wouldn't be concerned about delayed timer handling because most of the things there can be delayed. Anything series should receive a wakeup right away. It could result in delayed networking if timers go nuts. > 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] ktimers runs at a RT priority so that ksoftirqd, with all its things, doesn't have to. Which is odd because that one usually shouldn't run. Usually, if the networking interrupt is scheduled, it should boost ktimers to completion and then add NET_RX. This then should not be picked up by ktimers but only run within the threaded interrupt. > Best regards, > Felix > Sebastian
