[RFC PATCH 0/4] USB: HCD/EHCI: giveback of URB in tasklet context

[Ming Lei]

On Fri, Jun 14, 2013 at 8:35 AM, Greg Kroah-Hartman
<gregkh at linuxfoundation.org> wrote:
> On Thu, Jun 13, 2013 at 03:41:17PM -0400, Alan Stern wrote:
>> On Thu, 13 Jun 2013, Greg Kroah-Hartman wrote:
>>
>> > On Thu, Jun 13, 2013 at 10:54:13AM -0400, Alan Stern wrote:
>> > > On Thu, 13 Jun 2013, Ming Lei wrote:
>> > >
>> > > > - using interrupt threaded handler(default)
>> > > >         33.440 MB/sec
>> > > >
>> > > > - using tasklet(#undef USB_HCD_THREADED_IRQ)
>> > > >         34.29 MB/sec
>> > > >
>> > > > - using hard interrupt handler(by removing HCD_BH in ehci-hcd.c )
>> > > >         34.260 MB/s
>> > > >
>> > > >
>> > > > So looks usb mass storage performance loss can be observed with
>> > > > interrupt threaded handler because one mass storage read/write sectors
>> > > > requires at least 3 interrupts which wake up usb-storage thread 3 times
>> > > > (each interrupt wakeup the usb-storage each time), introducing irq threaded
>> > > > handler will make 2 threads to be waken up about 6 times for one read/write.
>> > > >
>> > > > I think usb mass storage transfer handler need to be rewritten, otherwise
>> > > > it may become worsen after using irq threaded handler in USB 3.0.(the
>> > > > above device can reach >120MB/sec with hardware handler or tasklet handler,
>> > > > which means about ~3K interrupts/sec, so ~6K contexts switch in case of
>> > > > using irq threaded handler)
>> > > >
>> > > > So how about supporting tasklet first, then convert to interrupt
>> > > > threaded handler
>> > > > after usb mass storage transfer is rewritten without performance loss?
>> > > > (rewriting
>> > > > usb mass storage transfer handler may need some time and work since storage
>> > > > stability/correctness is extremely important, :-)
>> > >
>> > > Maybe we should simply copy what the networking people do.  They are
>> > > very concerned about performance and latency; whatever technique they
>> > > use should be good for USB too.
>> >
>> > Yes, but for "old-style" usb-storage, is this really a big deal?  We are
>> > still easily hitting the "line-speed" of USB for usb-storage with simple
>> > machines, the bottlenecks that I'm seeing are in the devices themselves,
>> > and then in the USB wire speed.
>>
>> What about with USB-3 storage devices?  Many of them still use the
>> bulk-only transport instead of UAS.  They may push the limits up.
>
> Are they really?  Have we seen that happen yet?  With the number's I've

Yes, the device I am testing is bulk-only, no uas support , and it is very
popular in market.

> seen published, we are easily serving up enough data to keep the pipe
> full, but that all depends on your CPU / host controller.
>
>> > Once hardware comes out that uses USB streams, and we get device support
>> > for the UAS protocol, then we might have a need to change things, but at
>> > this point in time, for the "old" driver, I think we are fine.
>> >
>> > Unless someone has a workload / benchmark that shows otherwise?
>>
>> The test results above show a 2.4% degradation for threaded interrupts
>> as compared to tasklets.  That's in addition to the bottlenecks caused
>> by the device; no doubt it would be worse for a faster device.  This
>> result calls into question the benefits of threaded interrupts.
>>
>> The main reason for moving away from the current scheme is to reduce
>> latency for other interrupt handlers.  Ming gave two examples of slow
>> USB code that runs in hardirq context now; with his change they would
>> run in softirq context and therefore wouldn't delay other interrupts so
>> much.  (Interrupt latency is hard to measure, however.)
>
> Yes, I know that people keep wanting to worry about latency issues, and
> the best answer for them has always been, "don't use USB." :)

I think we can do it better, why don't do it? :-)

> You suffer throughput issues with predicitable latency dependancies, so

This patchset don't cause throughout degradation but decrease latency much,
also has other advantages.

> we need to be careful we don't slow down the 99% of the systems out
> there that do not care about this at all.

Considered great amount of ARM devices in market, I think we need to
consider the problem on these devices, :-)

Thanks,
--
Ming Lei