high interrupt latency due to usb_sg_wait()
[Second transmission; hopefully this one will go through...] Alan, How about the attached patch? Works for me but definitely needs more review and testing. --david -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: high interrupt latency due to usb_sg_wait()
On Mon, 7 Mar 2016, David Mosberger wrote: > We are seeing relatively high interrupt latencies due to usb_sg_wait() > calling usb_submit_urb() with interrupts disabled (as a result of its > spin_lock_irq() call). > > As far as I can see, io->lock protects io->status and it's not really > necessary to hold the lock (or disable interrupts) during the > usb_submit_urb() call. It looks like you're right. The important races here are against sg_complete() and usb_sg_cancel(). On the other hand, it looks like io->urb[i]->dev does need to be protected by the spinlock, which it isn't in usb_sg_cancel() or sg_complete(). > Note that the current code doesn't protect against multiple concurrent > calls to usb_sg_wait(): a second caller of usb_sg_wait() could acquire > io->lock when the first caller drops it after calling usb_submit_urb() > and then it could resubmit the same URBs before the first caller gets > a chance to update io->status. This is perhaps an outright bug? There can't be multiple concurrent calls to usb_sg_wait(). Or, if there are, it's already a bug. > Am I missing something? I think you're basically right. Want to submit a patch? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
high interrupt latency due to usb_sg_wait()
We are seeing relatively high interrupt latencies due to usb_sg_wait() calling usb_submit_urb() with interrupts disabled (as a result of its spin_lock_irq() call). As far as I can see, io->lock protects io->status and it's not really necessary to hold the lock (or disable interrupts) during the usb_submit_urb() call. Note that the current code doesn't protect against multiple concurrent calls to usb_sg_wait(): a second caller of usb_sg_wait() could acquire io->lock when the first caller drops it after calling usb_submit_urb() and then it could resubmit the same URBs before the first caller gets a chance to update io->status. This is perhaps an outright bug? Am I missing something? --david -- eGauge Systems LLC, http://egauge.net/, 1.877-EGAUGE1, fax 720.545.9768 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
