Re: usb with fast interrupts

M. Warner Losh wrote:
> In message: <41952FBD.40602_at_freebsd.org>
>             Scott Long <scottl_at_freebsd.org> writes:
> : M. Warner Losh wrote:
> : > Our usb system supports soft interrupts, but we currently don't make
> : > productive use of them.  The following makes interrupts fast
> : > interrupts and uses taskqueues to queue data to a SWI.
> : > 
> : > Lemme know if it works for you.
> : > 
> : > Warner
> : > 
> : 
> : Taskqueues aren't good for timing-sensitive operations.  Even though USB
> : may not be terribly sensitive, I bet you'll actually see performance
> : drops with things like umass with this.  Could you instead just put the
> : real handler into a kthread and wake it up, or use a swi?
> 
> I'll have to measure, but I've not seen my umass get any slower with
> this patch...  I can't use a SWI, because there's no way to turn off
> an SWI once you've created it (and I think you'd said you were opposed
> to creating a SWI cleanup function).  I'm not sure how a kthread would
> be any faster, however, since both a taskqueue and a thread have to go
> through a scheduling point.
> 
> A quick test here seems to point out a bug in da:
> sudo dd if=/dev/da0 of=/dev/null
> ^C5275+0 records in
> 5275+0 records out
> 2700800 bytes transferred in 26.385502 secs (102359 bytes/sec)
> 3:06pm hammer:[68]> dmesg | egrep da
> da0 at umass-sim0 bus 0 target 0 lun 0
> da0: <Sony MSC-U04 3.00> Removable Direct Access SCSI-0 device 
> da0: 3MB (7904 512 byte sectors: 64H 32S/T 3C)
> 
> Hmmm, how can I read more than 3MB from da0?  I'll have to check to
> see how fast it is w/o this change.
> 
> Warner

The problem with a taskqueue is that you are the slave to other drivers
that want to do slow and expensive things in it.  If someone else's
taskqueue sleeps, you won't run until it wakes up.  You might not see
much effect of this on an unloaded system, but there certainly is lots
of taskqueue code out there that is slow and heavy.

Taskqueues are good for when a driver has handled the interrupt and
wants to offload a heavy and/or non-time-critical function out of the
fast path.  They really aren't good for handling an entire driver ISR.

Scott