usb with fast interrupts
Stephan Uphoff
ups at tree.com
Fri Nov 12 15:11:36 PST 2004
On Fri, 2004-11-12 at 17:21, M. Warner Losh wrote:
> In message: <419536C0.5040807 at freebsd.org>
> Scott Long <scottl at freebsd.org> writes:
> : 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.
>
> In this case we have handled the time critical part of the ISR. It
> acks things and then queues the 'slow' stuff, which is basically
> everything. On Open/NetBSD this part of the code already runs in a
> SWI. The point about sharing the taskqueue with other drivers is a
> valid one that I'd not considered...
>
> Warner
If you are running i386 with PREEMPTION you may want to try this patch:
Index: intr_machdep.c
===================================================================
RCS file: /cvsroot/src/sys/i386/i386/intr_machdep.c,v
retrieving revision 1.11
diff -u -r1.11 intr_machdep.c
--- intr_machdep.c 3 Nov 2004 18:03:06 -0000 1.11
+++ intr_machdep.c 11 Nov 2004 22:31:19 -0000
@@ -205,7 +205,9 @@
isrc->is_pic->pic_eoi_source(isrc);
error = 0;
/* XXX */
+#if 0
td->td_pflags &= ~TDP_OWEPREEMPT;
+#endif
critical_exit();
} else {
/*
Otherwise preemption to SWI is disabled if triggered by a fast
interrupt. On a busy system it may take a while until until the SWI is
serviced (Longer than without PREEMPTION!)
jhb@ agrees that the line "td->td_pflags &= ~TDP_OWEPREEMPT;" is no
longer needed. The patch just needs more testing and I don't have
hardware that really stresses fast interrupts.
( No I am NOT setting up a serial PPP connection for testing purposes!)
Stephan
More information about the freebsd-current
mailing list