On Tue, Aug 22, 2017 at 12:42:33PM -0600, David Mosberger wrote: > Has anyone here looked into reducing the amount of time the USB serial > driver disables interrupts? On an ARM system, I'm seeing about 746 us > of latency for handling a USB interrupt, which seems rather excessive. > I attached a trace captured with the irqsoff tracer. USB has always been a big problem with this, the IRQ patch is very long, and messy and complex. There was an option a while ago to turn USB irqs into threaded irqs, do those work on your platform? If so, that might help you out here. The usb-serial path should be really "short" overall, compared with the ohci and tty core logic involved. What USB-serial driver is this that you are using here? > > Note: the 500MHz ARM cycle counter was used for timestamping > the entry so the reported times have to be doubled to get actual time > in micro-seconds. > > >From what I can see: > > o OHCI takes interrupt and frees up an URB that is done > o USB serial driver submits a new URB (for transmit, I think) > o another URB is freed (receive, I think), then a new receive URB is > submited > > I'm hoping there is something silly going on and things are done at the > hardirq level when they should be done as softirqs, but I just started > looking into this. > > Anyone have any helpful thoughts/pointers? Don't ever use USB on a device that you care about IRQ timing :) Seriously, it's a mess, all because of the hardware involved... good luck! greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
