> On Wed, 6 Nov 2013, Nebojša Ćosić wrote: > > You can try with this patch. I am quite sure that same problem > > persists on all newer kernels (I am using 2.6.33), but never had a > > time to create simple test to prove it. > > I'm looking forward to your detailed analysis .... > > > Index: net/sched/sch_generic.c > > =================================================================== > > --- net/sched/sch_generic.c (revision 1709) > > +++ net/sched/sch_generic.c (revision 1710) > > @@ -120,16 +120,18 @@ > > int ret = NETDEV_TX_BUSY; > > > > /* And release qdisc */ > > - spin_unlock(root_lock); > > +/* spin_unlock(root_lock); > > > > HARD_TX_LOCK(dev, txq); > > +*/ > > Do you really think this locking scheme is just for fun? > qdisk_lock, i.e. root_lock and the netif_tx_lock are mutually > exclusive for a reason. Reading the documentation and > comments of code is optional, right? > > > > > When transmit queue is empty, thread wanting to send a message > > > > comes directly to sch_direct_xmit, without changing context. It > > > > then releases spin lock, and than takes another. So far so good. > > > > If this starting thread is of lower priority, it can be > preempted > > > > by another thread, while still being in dev_hard_start_xmit > > > > function This thread will check if HARD_TX_LOCK is > taken, and if > > > > so, go on and queue its own message. If there are > enough higher > > > > priority tasks, tx can be stalled indefinitely. [..] > > Utter nonsense. In my situation if a first thread is preempted in dev_hard_start_xmit, then a second thread which transmits over the same interface sees a none empty queue and just enqueue the skb in the queue. No transmit (HARD_TX_LOCK) is necessary because the first thread is already working on the queue. Please correct me if I'm not right. For my case the first thread does normal SSH communication and the second thread does real-time UDP communication. This results in a priority inversion for the transmission of skb's over the same network interface. Is there any chance to get rid of this priority inversion? Maybe with priority qdisc? > The code (sch_direct_xmit) you are modifying is called from > exactly two places: > > 1) __dev_xmit_skb > > 2) __qdisc_run() > > Which in turn two call sites: > > 1) __dev_xmit_skb() either directly or via qdisc_run() > > 2) net_tx_action() which is the NET_TX softirq action > > None of those calls does a trylock on the xmit lock. So what > the heck are you talking about? > > Thanks, > > tglx regards, gerhard-- 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
