Re: usb with fast interrupts

On Fri, 12 Nov 2004, M. Warner Losh wrote:

> : 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. 

It's not a question of how fast the taskqueue thread it's scheduled, it's
how quickly it finishes all the other stuff it's doing before it gets to
your work.  Specifically, we defer all kinds of funny things to run in a
task queue "eventually" as they can't be run in the context where they are
scheduled, and those activities may take pretty variable amounts of time
to complete.  For example, the vrele() of the root vnode of a jail is
performed in a task queue because crfree() is called in situations where
it can't block (such as tear-down of TCP contexts).  vrele() not only
requires giant, but also potentially calls VOP_INACTIVE(), which calls
back into the file system and may perform synchronous I/O as part of
deleting a file.  So depending on the task you waited for, you might find
yourself with high variability in delay, and potential worst case delays
of several disk seeks before your task ran.

Right now we define two worker task queues in subr_taskqueue.c: an MPSAFE
swi and a SWI with Giant.  Several other task queues also exist, including
at least one or two for ACPI.  I notice that USB already has a task
thread, but that it has a manually constructed task mechanism.  Depending
on how you feel about frobbing that code, it might make sensee to unify
USB using a single task thread and the task queue abstraction.

Robert N M Watson             FreeBSD Core Team, TrustedBSD Projects
robert_at_fledge.watson.org      Principal Research Scientist, McAfee Research


> 
> 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
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>