Re: usb with fast interrupts

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
_at__at_ -205,7 +205,9 _at__at_
                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_at_ 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