Date: Sat, 13 Nov 2004 08:31:39 +0000 (GMT) From: Robert Watson <rwatson@freebsd.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: current@freebsd.org Subject: Re: usb with fast interrupts Message-ID: <Pine.NEB.3.96L.1041113082117.26498E-100000@fledge.watson.org> In-Reply-To: <20041112.150905.105578119.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1041113082117.26498E-100000>