Re: usb with fast interrupts

Stephan Uphoff wrote:
> 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
> 

I've actually been testing with this line turned off for quite a while.
It no longer makes a difference for stability.

Scott