On Tue, Oct 04, 2016 at 02:33:08PM +0000, Koehrer Mathias (ETAS/ESW5) wrote: > Hi Julia, Hey Mathias- > > Which, looks to me to be the normal "forced primary" interrupt handling path, which > > simply wakes the created irqthread. > > > > However, what isn't clear from the data is _which_ irqthread(s) is being woken up. > > Presumably, due to the prior igb traces, it's one of the igb interrupts, but that would > > be nice to confirm using the sched_wakeup event or other means. > > [..] > In the meanwhile I have detected another finding which might be relevant: > > With the 3.18 kernel the igb driver comes with two interrupts per NIC (e.g. eth2 and eth2-TxRx0) > with the 4.6. kernel the igb driver comes with 9 (!) interrupts per NIC: > eth2, and eth2-TxRx-0, eth2-TxRx-1, ... , eth2-TxRx-7. > > As I have used initially the same kernel configuration from 3.18 also > for the 4.6. kernel I wonder where this comes from and if there is any > kernel option I may use to disable these many interrupts and to reduce > it to 2 again. If it's all of these interrupts that are firing and being handled at the same time, that can account for the latencies you were seeing. As I suggested before, having a trace with the sched_wakeup event enabled can help confirm that it's these interrupts causing problems. If it is true, then the question is: why is the device triggering all of these interrupts all at once? Is that expected? These are questions for netdev folks, I think. Julia -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
