> -----Original Message----- > From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb- > owner@xxxxxxxxxxxxxxx] On Behalf Of Sarah Sharp > Sent: Saturday, June 18, 2011 12:30 AM > To: Xu, Andiry > Cc: Alan Stern; linux-usb@xxxxxxxxxxxxxxx; matthew.r.wilcox@xxxxxxxxx > Subject: Re: [PATCH 5/5] xHCI: assign devices to different interrupters > > On Fri, Jun 17, 2011 at 03:49:15PM +0800, Xu, Andiry wrote: > > I did this simply because xHCI driver uses MSI-X as default since > > 2.6.36, > > but only supports one interrupt vector, and other vectors allocated > > never have interrupts. To fully utilize the MSI-X vectors, > interrupters > > are needed. > > Sure, but if there's no performance gain to multiple event rings, we > would just be adding complexity (opening the potential for more bugs). > Just because an optional feature is there in the spec doesn't mean we > need to use it. MSI and MSI-X are still useful by itself to get the > xHCI host off the shared legacy IRQs. (Although if we only use one > event ring, we really should only be allocating one MSI-X vector.) > > > What about the mechanism below? > > > > Interrupter 0: IMODI = 160 > > Assign all devices' ctrl transfer to it > > Interrupter 1-n: IMODI = 0 (interrupt ASAP) > > Assign devices' bulk/intr/isoc transfers. > > > > As Alan pointed out, all other transfers should have latency as small > as > > possible. > > > > I've done some tests with USB3.0 storage device. IMODI=0 does help > > improve the performance, though not significantly. > > Was that a BoT device or a UAS device? Could you share your > performance > test and numbers? > > If there's not much performance gain, the question becomes, why not > just > set IMODI=0 for the one event ring and put all transfers on it? Would > there be a performance hit to any other devices in the system if we > just > kept one event ring? Control transfers really don't happen all that > often. > > I'm concerned that even if we do run tests with multiple event rings > with UAS, we really won't see any gains because the xhci->lock > essentially makes the whole system serialized. It would be interesting > to run perf on the xHCI driver with multiple event rings and see if > there is any serious lock contention, or the driver needs other > performance improvements. > > If there is serious lock contention with multiple event rings, then > there probably needs to be further work done to move to a different > locking scheme before we're going to see any really good performance > gain out of multiple event rings. > > But all of this is just speculation until I see some performance > numbers and perf charts. :) > OK, I've got your point. I will hold off the patches until solid performance gain can be acquired. Thanks, Andiry -- 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
