On 02/29/2016 07:40 AM, Mike Galbraith wrote: > On Mon, 2016-02-29 at 07:03 -0800, Peter Hurley wrote: > >>> If I'm listening properly, the root cause is that there is a timing >>> constraint involved, which is being exposed because one softirq raises >>> another (ew). >> >> Not the case. The softirq is raised from interrupt. > > Yeah, saw that on re-read. > >> Before Eric's change, when an interrupt raises a new softirq >> while processing another softirq, the new softirq is immediately >> processed *after the existing softirq completes*. > > Not necessarily, Eric only changed it from an arbitrary count to an > arbitrary time, so your irq could just as well land when there's no > count left and be up the same creek. Your misreading the softirq abort logic: neither 2ms nor a fixed number of loops has elapsed. All that's happened is the first loop of NET_RX softirq has woken a process; that is sufficient to abort softirq and defer it for ksoftirqd. That's why I'm saying this is a priority inversion, and one that will happen a lot. > I was more infatuated by the constraint that's left dangling in the > breeze any time processing is deferred to ksoftirqd. > > -Mike > -- To unsubscribe from this list: send the line "unsubscribe dmaengine" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
